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ABSTRACT 



A method of managing reliance in an electronic transaction 
system includes a certification authority issuing a primary 
certificate to a subscriber and forwarding to a reliance server, 
information about the issued primary certificate. The re fi- 
ance server maintains the forwarded information about 
issued primary certificate. The subscriber forms a transac- 
tion and then provides the transaction to a relying party. The 
transaction includes the primary certificate or a reference 
thereto. The relying party sends to the reliance server a 
request for assurance based on the transaction received from 
the subscriber. The reliance server determines whether to 
provide the requested assurance based on the information 
about the issued primary certificate and on the requested 
assurance. Based on the determining, the reliance server 
issues to the relying party a secondary certificate providing 
the assurance to the relying party. 

56 Claims, 12 Drawing Sheets 
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RELIANCE SERVER FOR ELECTRONIC 
TRANSACTION SYSTEM 

1. FIELD OF THE INVENTION 

This invention relates to electronic transactions, and, 
more particularly, to services supporting reliance on digital 
signature certificates and managing the risk of such certifi- 
cates in an electronic transaction system. 

2. BACKGROUND OF THE INVENTION 

Systems for accomplishing business transactions elec- 
tronically are becoming increasingly widespread, partly 
because of the advent of global computer networks such as 
the Internet, and partly because of the evolution and maturity 
of public key cryptography, which enhances the security of 
such commerce. The application of public key cryptography 
to electronic commerce has been heretofore envisioned in 
documents such as Recommendation X.509 of the Interna- 
tional Telecommunications Union (ITU, formerly CCITT) 
(hereinafter "Standard X.509"), the Digital Signature Guide- 
lines of the American Bar Association's Information Secu- 
rity Committee (December 1995 edition, hereinafter "ABA 
Guidelines"), and statutes and regulations such as the Utah 
Digital Signature Act, Utah Code Ann. title 46, chapter 3 
(1996) (hereinafter "Utah Act"). 

The backdrop established in these and other documents 
addresses some problems but leaves many of them unsolved 
and unresolved. 

2.1 Conventional Approaches to Digital Signature 
Certification 

To use secure electronic commerce according to the 
conventional methods, each user has a pair of related keys, 
namely a private key (to be kept secret by the user) and a 
public key (which can be known by anyone without com- 
promising the secrecy of the corresponding private key). 
Using a particular public key, an algorithm can determine 
whether the corresponding private key was used to sign or 
authenticate a given message. For example, if A wishes to 
send B a message, and provide B with a high degree of 
assurance that the message is genuinely A*s, then A can 
digitally sign the message using A's private key, and B can 
thereafter verify that the message is truly A's using A's 
public key. 

A public key is simply a value (generally a number), and 
has no intrinsic association with anyone, including the 
person whose message it is to authenticate. Widespread, 
commercial use of digital signatures requires reliable infor- 
mation associating public keys with identified persons. 
Messages of those identified persons can then be authenti- 
cated using the keys. 

Digital signature certificates (sometimes also called pub- 
lic key certificates or simply certificates) meet this need. 
These certificates are generally issued by trusted third par- 
ties known as certification authorities (CAs) and they certify 
(1) that the issuing certification authority has identified the 
subject of the certificate (often according to specifications 
delineated in a certification practice statement), and (2) that 
a specified public key (in the certificate) corresponds to the 
a private key held by the subject of the certificate. A structure 
for public-key certificates is included in the X.509 standard 
cited earlier The content of a certificate is often specified in 
a statute or regulation. A typical X.509 certificate has the 
format shown in FIG. 1. 

In order to assure that a certificated authenticity can be 
subsequently verified, the certification authority digitally 
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signs the certificate when issuing it. The issuing certification 
authority's digital signature can itself be verified by refer- 
ence to a public key (the certification authority's public key), 
which is associated with the certification authority in another 

s certificate issued by a second certification authority to the 
first certification authority. That other certification authori- 
ty's digital signature can be verifiable by a public key listed 
in yet another certificate, and so on along a chain of 
certificates until one reaches a so-called root or prime 

10 certification authority whose public key is widely and reli- 
ably distributed. For maximum assurance of the authenticity 
of a certificate relied upon in a transaction, the relying party 
must, using conventional methods, verify each certificate in 
the chain. An example of a certification chain is shown in 

is FIG. 2, wherein a root certification authority issues a cer- 
tificate to certification authority CA-1 which in turn certifies 
certification authorities CA-2 and CA-5. Certification 
authority CA-2 certifies CA-3 which certifies CA-4 which 
certifies subscriber-1. Certification authority CA-5 certifies 

20 subscriber-2. 

Most legal systems treat a certificate as a representation, 
finding, or conclusion made pursuant to a contract between 
the issuing certification authority and the subscriber, i.e., the 
person identified in the certificate as the holder of the private 

25 key corresponding to the public key listed in the certificate. 
Persons other than the subscriber may rely on the certificate. 
The certification authority's duties in relation to those rely- 
ing parties may stem from rules governing representations or 
false statements, rules treating the relying party as a third - 

30 party beneficiary of the contract between the certification 
authority and subscriber, statutes governing digital 
signatures, or a blend of all of the above as well as perhaps 
additional legal principles. 

Often, a party's right to rely on a certificate is limited. In 

35 the law applicable to misrepresentations, for example, reli- 
ance is generally required to be reasonable. Further, reliance 
on some certificates is specified to be per se unreliable. A 
bright line separates certain classes of clearly unreliable 
certificates from all others, and a relying party relies on them 

40 at its own peril, without recourse against the issuing certi- 
fication authority or subscriber for a defect in the certificate. 
Certificates that are per se unreliable are conventionally 
termed invalid, and may include any certificate which: 

45 (1) Has expired (i.e., the time of reliance is later than the 
date specified in the certificate for its expiration); 
(2) Has been revoked (i.e., have been declared perma- 
nently invalid by the certification authority which 
issued the certificate); and 

50 (3) Is suspended at the time of reliance (i.e. has been 
declared temporarily invalid by the certification author- 
ity which issued the certificate). 
In addition, a certificate which has not been accepted by 
its subscriber or issued by a certification authority should not 

55 be considered to have taken effect, and could, perhaps rather 
loosely, be considered invalid. 

Suspending and/or revoking certificates are an important 
means of minimizing the consequences of errors by the 
certification authority or subscriber. Depending on appli- 

60 cable legal rules, a certification authority may avert further 
loss due to inaccuracy in the certificate by revoking it. A 
subscriber can revoke a certificate to prevent reliance on 
forged digital signatures created using a compromised, e.g., 
lost or stolen, private key. Certificates which become invalid 

65 by revocation are generally listed in a certificate revocation 
list (CRL), according to ITU X.509. Suspension, or tempo- 
rary invalidation, was not contemplated in ITU X.509, and 
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may or may Dot be included in the CRL. Certificates which 
become invalid by virtue of their age need not be listed in a 
CRL because each certificate contains its own expiration 
date. 

As a practical matter, the conventional CRL-based system s 
works as follows. Before a subscriber can create a verifiable 
digital signature, the signer must arrange for a certification 
authority to issue a certificate identifying the subscriber with 
the subscriber's public key. The subscriber receives back 
and accepts the issued certificate, and then creates digital 10 
signatures and attaches a copy of the certificate to each of 
them. When the other party to a transaction receives such a 
digital signature, the other party must check with the certi- 
fication authority, generally via its on-line database, to 
determine whether the certificate is currently valid. If so, and 15 
if the digital signature can be verified by the public key in 
the certificate, the party is usually in a strong position to rely 
on the digital signature. 



2.2 Problems with the Conventional Approaches to 
Digital Signature Certification 



20 



25 



The system summarized above and envisioned in Stan- 
dard X.509, the ABA Guidelines, the Utah Act, and similar 
documents has several deficiencies, including: 

Little support for risk management: The conventional 
system provides very few facilities or opportunities to 
enable a certification authority to manage the risk of 
certification. The certification authority is not informed 
when anyone relies on a certificate that the certification 30 
authority has issued or the extent to which anyone 
relies on any certificate it has issued. The certification 
authority also has no way of monitoring outstanding 
certificates, ascertaining whether problems arise, evalu- 
ating which factors affect the risk of faulty certification 35 
or the scope of exposure to risk that the certification 
authority should prudently undertake. Furthermore, 
conventional systems provide few facilities to help 
subscribers and relying parties manage their risks, 
including the risk of keeping the private key secure. 40 

Relying party is under-served: To a great extent, it is the 
relying party, not the subscriber, who bears the risk of 
fraud or forgery in the transaction. If a document is 
forged or is fraudulently altered, the relying party will 
suffer the consequences, which, according to the law of 45 
most states, is that the message is treated as void. 
Although the relying party has the keenest interest in 
the information security of the transaction, the certifi- 
cation authority's service contract is entirely with the 
subscriber. In the case of a fraud or forgery, the 50 
subscriber may even be the perpetrator. The roles of the 
conventional system thus set the certification authority 
up to deal with relatively disinterested parties or even 
perpetrators in problem cases, but to have no contact 
with the party who primarily bears the loss. This state 55 
of affairs exposes the certification authority to serious 
liability risks in relation to the relying party and causes 
the certification authority to forgo the business oppor- 
tunity of serving the relying party. Rather than dealing 
exclusively with the subscriber, the digital signature 60 
infrastructure also needs a way of dealing with the 
relying party. 

Cost front-loaded onto subscriber: Since the certification 
authority's contract is with the subscriber alone, not 
with the relying party, the certification authority has no 65 
alternative but to recover all costs and profit from the 
subscriber, even though, as previously noted, the rely- 



ing party has the principal interest in the security of the 
signed message. 
Lack of robustness: Because the conventional system fails 
to address risk management and the needs of relying 
parties, certification authorities have tended to interpret 
their roles narrowly. A certification authority may, for 
example, promise to look by rote at an apparent driver's 
license, or accept at face value a notarized application 
for certification, without purposefully endeavoring to 
serve the real business need for certification, which is 
to assure the expectations of the parties to the transac- 
tion. This mechanical approach to certification limits 
the potential for CAs to add further value to electronic 
commerce transactions. A more robust system needs to 
be serviceable for certifying authorization, 
accreditation, legal status of a juridical entity, and 
credit, for example. 

SUMMARY OF THE INVENTION 

This invention solves the above and other problems by 
providing in an electronic transaction system, a reliance 
server, an information processing system, which includes 
some or all of the following features: 

(1) Contracts with the relying party, the party receiving 
and potentially relying on the subscriber's digital 
signature, to perform services as requested by the 
relying party. 

(2) Automatically performs services as requested by the 
relying party, services which may include certifying the 
validity and authenticity of the subscriber's certificate 
and providing additional assurance of the accuracy and 
reliability of that certificate in the form of a secondary 
certificate tailored to the relying party's needs. A sec- 
ondary certificate is a certificate that is issued auto- 
matically based on another certificate and perhaps 
additional information gathered and maintained by the 
reliance server. 

(3) Monitors the scope of its and the certification authori- 
ty's exposure in relation to valid certificates by retain- 
ing records of services performed in response to 
requests from relying parties. 

(4) Limits and manages the certification risk incurred by 
itself and the certification authority by evaluating rely- 
ing parties' requests in relation to certain criteria estab- 
lished in cooperation with the certification authority. 
Because the risk is bounded and managed, it is more 
readily insurable. 

(5) Informs the subscriber of reliance on the subscriber's 
certificate and the extent of such reliance and the 
amount of assurance issued by the reliance server. 
Frequent reports to the subscriber enable the subscriber 
to discover problems, and thereby share in the respon- 
sibility for timely remedial action, 

(6) Informs an insurer of the scope of its underwriting 
commitment by including the insurer in the information 
conduit that responds to relying party requests. 

As used herein, the term "party" generally refers to an 
electronic device or mechanism and the term "message" 
generally refers to an electronic signal representing a digital 
message. The terms "party" and "message" are used to 
simplify the description and explanation of the invention. 
The term "mechanism" is used herein to represent hardware, 
software or any combination thereof. The mechanisms and 
servers described herein can be implemented on standard, 
general-purpose computers or they can be implemented as 
specialized devices. 
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This invention is a method of managing reliance in an reliance server checking authenticity of the other certificate 
electronic transaction system. The method includes a certi- and issuing the secondary certificate attesting to the authen- 
tication authority issuing a primary certificate to a subscriber ticity of the other certificate. The checking includes verify- 
and forwarding, from the certification authority to a reliance ing the other certificate's digital signature along a chain of 
server, assurance parameters about the issued primary cer- S certificates, and checking whether the requested assurance is 
tificate. The reliance server maintains the forwarded infor- within the assurance parameters. 

mation about the issued primary certificate. The subscriber In some cases where the requested assurance is for the 

forms a transaction and then provides the transaction to a validity of another certificate the reliance server checks the 

relying party, the transaction including the primary certifi- current validity of the other certificate; and issues the 

cate issued by the certification authority or an identification 10 secondary certificate attesting to the validity of the other 

of that certificate. The relying party evaluates the transaction certificate. The checking includes determining whether the 

sent by the subscriber and determines whether some assur- other certificate has been suspended, revoked, or has 

ance on the authenticity of the primary certificate is needed expired, and checking whether the requested assurance is 

in order to "safely" proceed with the transaction. If the within the assurance parameters. 

relying party determines that assurance is needed, it sends to 15 In some cases where the requested assurance is for 

the reliance server a request for a specific amount of assurance of an agent's authority, the method includes the 

assurance based on the transaction received from the sub- reliance server returning documentation of agency with an 

scriber. Then the reliance server determines whether or not enveloping secondary certificate attesting to authenticity, 

to provide the requested assurance. The reliance server bases The documentation of agency includes a power of attorney, 

its determination on the requested assurance, the assurance 20 In some cases where the requested assurance is for 

parameters about the issued primary certificate received assurance of a person's accreditation, the reliance server 

from the certification authority, historical information about returns a statement by a licensing or professional body 

assurance that has been issued for this and other certificates regarding the person's accreditation, with an enveloping 

to the requesting relying party and other relying parties, and secondary certificate attesting to the statement's authentic- 

on any other information that might be available. Based on 25 ity. 

its determination, the reliance server issues to the relying In some cases where the requested assurance is for 

party a secondary certificate providing the assurance to the assurance of existence and/or good standing of entity, the 

relying party. reliance server returns a statement by a public office in 

In preferred embodiments, the primary certificate is a which the entity is incorporated indicating that the entity 

digitally signed electronic document of predefined format 30 exists, is in good standing, and is qualified to conduct 

within which a certification authority makes representations business, wherein statement is enclosed in the secondary 

intended for relying parties with which the subscriber will certificate attesting to the statement's authenticity, 

engage in transactions. This primary certificate can be, and In some cases where requested assurance is for assurance 

in many cases is, an X.509 certificate, as defined in the of the performance of an obligation, the reliance server 

standard cited earlier. Alternately, the primary certificate can 35 issues a statement of assurance of performance, wherein 

be a certificate which makes representations of the agency or statement is enclosed in the secondary certificate attesting to 

accreditation of a particular individual or organization, or the statement's authenticity. 

one which provides a promise of payment. Preferably the reliance server and the relying party enters 

In some cases the primary certificate specifies a reliance into a contract prior to the reliance server issuing the 

limit and the information forwarded by the certification 40 secondary certificate. The contract can be entered into after 

authority to the reliance server includes assurance param- the relying party makes its request. 

eters controlling whether the reliance server can provide The transaction can include a digital signature. 

assurance based on the primary certificate. The assurance parameters transferred from the certifying 

In some cases the assurance parameters include an accept- authority to the reliance server can include a maximum 

able reliance limit in excess of the reliance limit specified in 45 supplemental assurance that can be issued for a particular 

the primary certificate, and the request for assurance is a digital signature. In some cases the assurance parameters 

request for reliance on a value in excess of the specified include at least one of: 

reliance limit. In those cases, the reliance server determines \ m a maximum supplemental assurance that can be issued 

whether to provide the requested assurance by determining i n a single secondary certificate; 

whether the requested reliance would exceed the acceptable 50 2 a maximum supplemental assurance that can be issued 

reliance limit to any part icular relying party; 

In preferred embodiments, the method further includes « . , . , tl _ . , . , 

v ' t 1- . » j 3. a maximum supplemental assurance that can be issued 

the reliance server tracking cumulative liability associated . . n , . 4 A 

. it i( . f 11 -it . during one or more specified time intervals; 

with the primary certificate, and determining whether the . „ 

requested reliance would cause the cumulative liability to 55 4 * a maximum ™mber of secondary certificates that can 

exceed the acceptable reliance limit. be ™™ d on the P nmar y certificate; 

In some cases where the requested assurance is for the 5 * a maximum time period during which a secondary 

accuracy of another certificate, the method includes the certificate may remain valid; 

reliance server checking the current validity and authenticity 6 - a maximum reliance limit that can be listed in a 

of the other certificate and then issuing the secondary 60 secondary certificate valid for a specified transaction 

certificate attesting to the accuracy of the other certificate. tv P e ; 

The validity checking includes verifying the other certifi- 7. specific information that must be submitted by the 
cale's digital signature along a chain of certificates, and relying party along with its request in order to provide 
checking whether the requested assurance is within the a basis for the supplemental assurance; 
assurance parameters. 65 8. an amount of supplemental assurance that the sub- 
In some cases where the requested assurance is for the scriber has prepaid and restrictions on how that prepaid 
authenticity of another certificate, the method includes the assurance can be issued in a secondary certificate; 
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9. a requirement that the subscriber approve issuance of 
supplemental assurance by the reliance server for a 
secondary certificate to be issued to the relying party 
before a relying party's request for a secondary certifi- 
cate can be granted; 

10. thresholds which trigger a report being sent from the 
reliance server to the certification authority; 

11. how often the reliance server should report to the 
certification authority about the extent of supplemental 
assurance issued on the primary certificate; 

12. restrictions limiting disclosure of or access to the 
primary certificate to specified parties; 

13. requirements that the transaction be signed by addi- 
tional parties besides the subscriber, optionally specify 
who those additional parties are and what number of 
them must sign; 

14. a scale of the amount of supplemental assurance that 
can be issued based on the number and identity of 
additional parties that sign; and 

15. information regarding the validity of the primary 
certificate. 

Any of the assurance parameters can be restricted to a 
particular time period, including the entire period during 
which the primary certificate is valid. 

In another aspect, this invention is an electronic transac- 
tion system which includes a certification authority and a 
reliance server connectable to the certification authority. The 
certification authority issues primary certificates to subscrib- 
ers to the system. The reliance server receives from the 
certification authority information regarding the primary 
certificates issued by the certification authority. The reliance 
server issues, upon request from relying parties, secondary 
certificates to the relying parties, the issuing being based on 
the information provided by the certification authority and 
on information provided by the relying parties. 

In some embodiments at least one other party is connect- 
able to the reliance server, and the reliance server provides 
the secondary certificate to the other party prior to issuing 
the secondary certificate to the relying party. 

Preferably the reliance server digitally signs the second- 
ary certificate prior to issuing it to the relying party. 

In yet another aspect, this invention is a method of 
automatic replacement of a subscribers certificate, in an 
electronic transaction system in which a certification author- 
ity issues digital certificates to subscribers. The method 
includes, a subscriber creating a standby application for 
certification of a new key pair, digitally signing the standby 
application with a private key and then destroying the 
private key. The subscriber then includes the public key 
corresponding to the private key in a transactional certificate 
valid only for the standby application and forwards the 
transactional certificate to the certification authority. The 
certification authority, keeps the transactional certificate. 
Subsequently, the subscriber sends the standby application 
to the certification authority which verifies the digital sig- 
nature on the application by reference to the transactional 
certificate and then issues a new time-based certificate 
listing the public key indicated in the standby application. 

As envisioned in another embodiment of the present 
invention, someone wishing to verify a certificate-based 
digital transaction produces a reliance-check message 
including the certificates associated with the transaction and 
a copy of relevant parts of the transaction (including at least 
the monetary value encoded in the transaction). This 
reliance -check message is then sent to the reliance server. 
The reliance server, upon receipt of a reliance-check 
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message, checks the certificates for validity, and checks for 
various consistency problems that might indicate compro- 
mised trusted devices. The reliance server can also track the 
cumulative exposure to risk of each certification authority. If 
5 the reliance server determines that the risk is acceptable 
(based on the information in the reliance-check message and 
on other information it has stored or obtained), it returns a 
digitally signed reliance server response message to the 
relying party. 

J0 In another embodiment, this invention is a method of 
managing reliance in an electronic transaction system in 
which subscribers have digital time-based certificates issued 
by certification authorities. The method includes, by a rely- 
ing party receiving a transaction from a subscriber, the 
transaction including information regarding at least one 

15 time-based certificate of that subscriber. The relying party 
creates a message based on certificate information from the 
transaction, the message specifying an amount of the trans- 
action upon which the relying party intends to rely. The 
relying party then sends the message to a reliance server 

20 requesting a guarantee for the amount of the transaction 
upon which the relying party intends to rely. The relying 
party then receives a voucher from the reliance server in 
response to sending the message and then continues the 
transaction with the subscriber based on information in the 

25 voucher, 

In another aspect of this invention, the method includes, 
a reliance server receiving a reliance request message from 
a party, the message specifying an amount of a transaction 
upon which the party intends to rely and requesting a 

30 guarantee for the amount of the transaction, the message 
including certificate information derived from the transac- 
tion. The reliance server determines whether to provide a 
guarantee for the amount of the transaction and sends a 
voucher to the relying party, the voucher including an 

35 indication of whether the reliance server guarantees the 
amount of the transaction. The determining includes deter- 
mining whether certificates associated with the transaction 
have been revoked or suspended. 

The method includes receiving from the certification 

40 authority an actual reliance limit for a certificate; storing the 
actual reliance limit; and determining whether the requested 
amount would exceed the actual reliance limit. Preferably 
the reliance server maintains a cumulative liability for a 
certification authority. 

45 In another aspect, this invention includes, by a certifica- 
tion authority, issuing a time-based certificate to a 
subscriber, the certificate specifying a stated reliance limit 
and forwarding to a reliance server an actual reliance limit 
for the certificate, the actual reliance limit being different 

50 from the stated reliance limit. 

In another general aspect, this invention is a method of 
managing reliance in an electronic transaction system in 
which subscribers have digital certificates. A relying party 
receives a transaction from a subscriber, the transaction 

55 including information regarding at least one certificate of 
that subscriber. The relying party creates a message based on 
certificate information from the transaction, the message 
specifying an aspect of the transaction upon which the 
relying party intends to rely; and then sends the message to 

60 a reliance server requesting a guarantee for the aspect of the 
transaction upon which the relying party intends to rely. 
Subsequently, the relying party receives a reply receipt from 
the reliance server in response to the step of sending the 
message; and continues the transaction with the subscriber 

65 based on information in the reply receipt. 

In some cases the subscriber's certificates have associated 
fees and the reliance server ascertains a fee for its services 
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based on the fees of certificates associated with the trans- 
action. The fees include usage fees, guarantee fees and 
lookup fees. 

In some cases when the message requested certificate 
status checks, the reply receipt indicates whether the cer- 
tificate status checks were acceptable. Generally, the receipt 
indicates whether the reliance server guarantees the aspect 
of the transaction upon which the relying party intends to 
rely. 

In some cases, the aspect of the transaction upon which 
the relying party intends to rely specifies a monetary value 
and the receipt indicates whether the reliance server guar- 
antees the transaction for that monetary value. Preferably the 
reliance server bases its guarantee on information specified 
in a certificate associated with the transaction. 

In another aspect, this invention includes, by a reliance 
server, receiving a message from a party thereby requesting 
a guarantee for an aspect of the transaction, the message 
including certificate information derived from the transac- 
tion; validating information in the message to determine 
whether to provide the guarantee for the aspect of the 
transaction; and sending a reply receipt to the relying party, 
the reply receipt including an indication of whether the 
reliance server guarantees the aspect of the transaction. The 
validating includes determining whether certificates associ- 
ated with the transaction have been revoked or suspended. 
Sometimes the certificate information included in the mes- 
sage includes unique identifiers for certificates associated 
with the transaction, and the determining includes looking 
up unique certificate identifiers on certificate revocation 
lists. Preferably the determining is performed based on 
previously obtained information about certificates. 

In some case where the aspect of the transaction for which 
a guarantee is requested is a monetary reliance value, and 
where at least one certificate associated with the transaction 
specifies a monetary limit, the validating includes determin- 
ing whether the monetary reliance value is within the 
monetary limit specified in the certificate. 

The determining also can include obtaining a value of a 
current cumulative monetary liability for the certificate and 
then determining whether the sum of the monetary reliance 
value and the current cumulative monetary liability would 
exceed the specified monetary limit. Based on this 
determining, the current cumulative monetary liability is 
updated. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The above and other objects and advantages of the 
invention will be apparent upon consideration of the fol- 
lowing detailed description, taken in conjunction with the 
accompanying drawings, in which the reference characters 
refer to like parts throughout and in which: 

FIG. 1 shows the format of a typical X.509 certificate; 

FIG. 2 shows a typical certification hierarchy; 

FIG. 3 shows an overview of an electronic transaction 
system according to a first embodiment of the present 
invention; 

FIGS. 4 and 5 are data structures used by the system 
according to FIG. 3; 

FIG. 6 shows an overview of an electronic transaction 
system according to second embodiment of the present 
invention; 

FIG. 7 depicts the issuance of certificates to a user of the 
system of FIG. 6; 

FIG. 8 depicts a user's generation of a digitally signed 
transaction according to the present invention; 
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FIGS. 9 and 10 are flow charts depicting the operation of 
aspects of electronic transaction system according to the 
present invention; 

FIG. 11 shows a format of an X.509 certificate which 
s includes a reliance specification; and 

FIG. 12 illustrates various risk, time, and cost consider- 
ations. 

DETAILED DESCRIPTION OF THE 
PRESENTLY PREFERRED EXEMPLARY 
10 EMBODIMENTS 

As noted above, as used herein the term "party" generally 
refers to an electronic device or mechanism and the term 
"message" generally refers to an electronic signal represent- 
ing a digital message. The terms "party" and are used to 

15 simplify the description and explanation of the invention. As 
used herein, the term "mechanism" is used herein to repre- 
sent hardware, software or any combination thereof The 
mechanisms and servers described herein can be imple- 
mented on standard, general-purpose computers or they can 

20 be implemented as specialized devices, 
1. PREFERRED EMBODIMENT 
LA Overview of Preferred Embodiment 

An electronic transaction system 100 according to a 
preferred embodiment of the present invention is described 

25 with reference to FIG. 3. The system 100 includes a certi- 
fication authority mechanism 102 and a reliance server 104. 
Subscriber mechanism 106 and relying party mechanism 
108 enroll in the system 100 (by enrolling with the certifi- 
cation authority mechanism 102 and the reliance server 104, 

30 respectively) in order to participate in it. Upon enrollment in 
the system 100, a subscriber mechanism 106 is issued an 
electronic primary certificate 110 by the certification author- 
ity mechanism 102. This primary certificate 110 identifies a 
reliance server 104 and information about this certificate is 

35 provided to the reliance server 104 identified in the certifi- 
cate 110. 

Once enrolled, a subscriber mechanism 106 transacts with 
a particular relying party mechanism 108 by sending the 
relying party mechanism an electronic transaction 112 

40 including signed information 114. The relying party mecha- 
nism 108 determines an aspect of the electronic transaction 
112 upon which it intends/wishes to rely and sends to the 
reliance server 104 identified in the certificate 110 electronic 
signals representing a request 116 for a secondary certificate. 

45 The reliance server determines whether or not to issue the 
secondary certificate 118 to the relying party mechanism 108 
based on information in the request 116, on previous 
requests based on the primary certificate 110, and informa- 
tion that it has previously obtained from the certification 

50 authority mechanism 102 regarding the primary certificate 
110. 

It is assumed that in a practical implementation of this 
system contracts which clearly defined the roles and respon- 
sibilities of all involved parties will be entered into, either 

55 bilaterally or multilaterally, by those parties. One of the key 
functions of the reliance server is to assure that the relying 
party mechanism 108 has properly enrolled into the system 
by entering into required contracts. 

The contract with the relying party mechanism 106 is the 

60 principal means of making the rules and risk allocations of 
the system 100 applicable to the relying party. While the 
contract described herein should be consistent with the 
emerging law of digital signatures, it provides a uniform, 
worldwide set of norms, even in legal systems where no law 

65 has been designed specifically for digital signatures. 

The processes performed by each party and their respec- 
tive roles are described in more detail below. 
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1 .B Detailed Description of Preferred Embodiment 
l.B.l Certification Authority Issues Certificate to Subscriber 
A certification authority mechanism 102 issues a sub- 
scriber mechanism 106 a primary certificate 110. The pri- 
mary certificate is a digitally signed electronic document of 
predefined format within which a certification authority 
makes representations intended for relying parties with 
which the subscriber will engage in transactions. This pri- 
mary certificate can be, and in many cases is, an X.509 
certificate, as defined in the standard cited earlier. 
Alternately, the primary certificate can be one which makes 
representations of the agency or accreditation of a particular 
individual or organization, or one which provides a promise 
of payment. 

The form prescribed by Standard X.509, requires the 
certificate 110 to include information that identifies the 
subscriber mechanism 106, states the subscriber's public 
key, and uniquely identifies the certificate. In this 
embodiment, certificates are uniquely identified by a com- 
bination of the identity of the issuer and a serial number 
unique with respect to that issuer. In an X.509 certificate, the 
serial number field distinguishes a given certificate from all 
others issued by the same certification authority mechanism 
102. Consequently, the serial number is unique and never 
repeats among the certificates issued by a particular certifi- 
cation authority mechanism 102. Since a certification 
authority mechanism 102 bears a distinguished (or unique) 
name, the combination of the issuing certification authori- 
ty's distinguished name and the certificated serial number 
identifies that certificate from among all other certificates 
from any or all CAs. 

In some applications of this embodiment, in order to 
require the relying party to enter into a contract before 
relying on the primary certificate, the primary certificate 110 
may be in Standard X.509 form, except that its public key 
field is left blank and the algorithm identifier indicates a 
system relying exclusively on certificates issued directly 
from a reliance server 104. Alternatively or in addition, 
certain data in the certificate may be encrypted, and the 
algorithm identifier indicates a system capable of processing 
and removing the encryption, in order to make the encrypted 
data usable. 

In addition, based on Utah Act and possibly other statutes 
and regulations, the certificate 110 can lists a monetary 
amount, referred to as a "reliance limit" in the Utah, which 
is a quantified declaration by the issuing certification author- 
ity mechanism 102, in light of the degree of security and 
investigation supporting the certificate, of the maximum 
extent of reasonable reliance on the certificate in any given 
transaction without any further investigation. In the pre- 
ferred embodiment provides for a monetary amount to be 
entered into the primary certificate by the certification 
authority serving a purpose similar to that intended by the 
Utah Act's reliance limit, however, that amount is referred to 
in the preferred embodiment as the primary assurance limit. 

In the preferred embodiment, the primary assurance limit 
for each issued certificate is set to an amount which the 
certification authority mechanism 102 considers acceptable 
in view of its exposure to risk on the primary certificate 110 
based on the information that it has collected in identifying 
the subscriber mechanism 106. If a relying party mechanism 
108 receives signed information 114 (including a certificate 
110) from the subscriber mechanism 106, and the relying 
party mechanism 108 desires greater assurance than the 
primary assurance limit stated in the primary certificate 110 
affords, the relying party mechanism 108 must request a 
secondary certificate 114 from the reliance server 104 asso- 
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ciated with that primary certificate 110. The secondary 
certificate 114 ordinarily states a higher assurance limit than 
the primary certificate 110 on which it is based. Additional 
costs are incurred for risk management and quality assur- 
S ance for this secondary certificate 114 bearing a higher 
assurance limit, and either the subscriber mechanism 106, 
the relying party mechanism 108, or both can ultimately bear 
those costs. 

The certification authority mechanism 102 can set a low 
10 primary assurance limit in the certificate 110 to necessitate 
that potential relying parties apply to the reliance server 104 
specified in the certificate 110 to obtain supplemental assur- 
ance in the form of a secondary certificate 114 stating a 
assurance limit greater than the primary assurance limit. 
15 1.B.2 Certification Authority Sends Publish Certificate Mes- 
sage to Reliance server 

When the certification authority mechanism 102 issues a 
primary certificate 110 to a subscriber mechanism 106, it 
also sends a Publish Certificate Message 120 to the reliance 
20 server 104 which is to issue secondary certificates 118 based 
on the primary certificate U0, The Publish Certificate Mes- 
sage 120 includes the primary certificate 110 and supple- 
mental assurance (reliance) parameters 122. Multiple reli- 
ance servers 104 may do business in a market or similar 
25 economy, and the reliance server 104 which the certification 
authority mechanism 102 selects for publication of a cer- 
tificate generally depends on bargaining, contracting, and 
similar market dynamics. 

The supplemental assurance parameters 122 that accom- 
30 pany the primary certificate 110 in the Publish Certificate 
Message 120 include: 
1. The maximum supplemental assurance that the reliance 
server 104 can issue based on the primary certificate 
110, cumulated over the validity period of the primary 
35 certificate. (In other words, this amount is the total of 
all assurance limits for all secondary certificates issued 
by the reliance server 104 based on the primary cer- 
tificate 110 for as long as it is valid (i.e., for as long as 
it is not revoked or expired.)) 
40 2. The maximum supplemental assurance that can be 
issued for particular digital signature (as recorded in 
Signed Information 114). 
3. The maximum supplemental assurance that can be 
issued in a single secondary certificate 118. 
45 4. The maximum supplemental assurance that can be 
issued to any particular relying party mechanism 108 
during a time period, which may be the entire period 
during which the primary certificate 110 is valid. 
5Q 5. The maximum supplemental assurance that can be 
issued during one or more specified time intervals such 
as a second, minute, day, week, month, or year. 

6. The maximum number of secondary certificates 118 
that can be issued on the primary certificate 110 during 

55 a time period, which may be the entire period during 
which the primary certificate is valid. 

7. The maximum time period during which a secondary 
certificate 118 may remain valid. 

8. The maximum assurance limit that can be listed in a 
60 secondary certificate 118 valid for a specified transac- 
tion type. 

9. Any pricing limits factors which the publishing certi- 
fication authority mechanism 102 is entitled to state 
pursuant to the contract between the certification 

65 authority mechanism 102 and the reliance server 104. 

10. Specific information that must be submitted by the 
relying party mechanism 108 along with its request 116 
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for a secondary certificate 118 in order to limit or 18. Any other limitation or prerequisite for issuance of 

provide a basis for the supplemental assurance to be secondary certificates 118 or for providing supplemen- 

issued. Such information might include a specific class tal assurance to a relying party mechanism 108 based 

of certificate that has been promised to the relying on the primary certificate 110. 

party, specification of a transaction type for the docu- 5 The above specifications depend on enabling provisions 

ment in which the signed information 114 appears, a made in the contract between a certification authority 

second signature (such as by a person approving, mechanism 102 and a reliance server 104. 

endorsing, or otherwise, perhaps with limits, counter- The certification authority mechanism 102 can amend the 

signing the relying party's request), and similar rel- operative supplemental assurance parameters 122 by send- 

evant information. 10 ing an amended publish certificate message 120 to the 

11. The amount of supplemental assurance that the sub- reliance server 104 that published the certificate 110. The 
scriber mechanism 106 has prepaid and restrictions on amending publish certificate message 120 contains only 
how that prepaid assurance can be issued in a second- supplemental assurance parameters 122, includes the pri- 
ary certificate 118 based on any of the other parameters mary certificate 110 being updated, and the new supplemen- 
in this list. 1 5 ta l assurance parameters 122. 

12. Any requirement that the subscriber mechanism 106 1-B.3 Reliance Server Processes Publish Certificate Mes- 
approve issuance of supplemental assurance by the sa £ e 

reliance server 104 for a secondary certificate 118 to be When the reliance server 104 receives a P ublish certificate 

issued to the relying party mechanism 108 before a message 120 from a certification authority mechanism 102, 

relying party's request for a secondary certificate 118 20 il first checks the ^S^ 1 signature on the publish certificate 

can be granted message 120 and the enclosed primary certificate 110. II the 

13. Thresholds (the point at which a condition is reached [ eUance se ™ 1^ verifies the signatures (i e., if the sign.- 

that is greater than or less than a specific parameter, f res « v f' d \ 11 stores P ublish certlflcat * ?««8« ™ 

, c * a 1 i e i \ i° r archival and non-repudiation purposes and then extracts 

percentage of parameter, or specific level of parameter) . r . - . r L1 . , iC . ™. 

<L nr ** n „~ 5 . • , , ■ ' . ■ f _ iU i is information from the publish certificate message 120. The 

for assurance which trigger a report being sent from the , , . _ . K , , . . =\„ t 1in 

reliance server 104 to the certification authority mecha. extracted information includes the primary certificate 110 

nism 102. These thresholds apply to any or all of the and SU ? P ^ ental k T r ,t nCe f^, l22 ' ,™ e reban " 

, , , u * * j • j j .i • server 104 then checks the information against any specifi- 

above parameters and can be stated independently or in c . t1 * ;. \ , , 

, . j . r ♦.It. cations for supplemental assurance parameters applicable to 

relation to and/or dependent on other parameter thresh- . _^>r * * j i_ *i_ *ve »■ *u •< 

u P 1 *i_ l. u • 4 30 primary certificates issued by the certification authority 

olds. For example, a threshold may require a report r , 3 . . . . . . ./ 

u orxnr c *i_ • mechanism 102 in question (i.e., the certification authonty 

when 80% of the maximum assurance on primary . + M ?• a ^ • ^-n , nn\ j 

4 . f . 11fl . , j A i mechanism 102 that issued the primary certificate 110), and 

certificate 110 has been issued. As another example, a . .„ . * J . , J 

lL , . , . cnnf CiU stores the new certificate and its supplemental assurance 

threshold may require a report when 50% of the maxi- . ... A . . . ™ . c 

, ;• * . . j- - parameters in a readily retrievable manner. The information 

mum cumulative assurance has been issued in a given f , 4 ... A J . . A , inA . 

• , nrkfrr r 4 . 4 i i j . 35 is electronically stored by the reliance server 104 in a 

day and 90% of that assurance has been issued to a .. ' , A . J , , . L1 , 

\. , , . _^ , . certificate validity database so as to be accessible by the 

particular relying party mechanism 108. . * . _ . _ . A . J , 

„ f tr „ , +m , x server as shown in FIG, 4. The information is stored such 

14. How often the reliance server 104 -should report to the ± iveD identification of the ^ certificate 110, the 
certification authority mechanism 102 about the extent Te]imQQ servef 1Q4 fa able to readi] the le . 
of supplemental assurance issued on the primary cer- 4Q mental ^ nrance paramet ers 122 appUcable to secondary 

certificates issued or to be issued based on that primary 

15. Restrictions limiting disclosure of or access to the certificate. 

primary certificate 110 (or copies or information about cert ificate validity database includes, for each pri- 
or derived from it, including reports of its existence and mary cer tificate 110, its validity status (valid, revoked, 
validity) to specified persons (who must be eventually 45 expired or suspended), and the supplemental assurance 
be reliably identified before disclosure or access can be parameters 122 applicable to secondary certificates based on 
granted). me primary certificate, and links to account history and 

16. Any requirement that the signed information 114 be periodic reporting information. (Note that it is not necessary 
signed by additional parties besides the subscriber to have an expired status since each primary certificate 110 
mechanism 106 and optionally specify who those addi- 50 specifies its life span. However, specifying the expired status 
tional parties are and what number of them must sign, obviates the need to examine the actual certificate.) 

(i.e. a quorum of a larger set of parties may be allowed). 1 .B3.1 Summary of Subscriber Enrollment and Initial Cer- 

Optionally, a scale of the amount of supplemental tification 

assurance that can be issued based on the number and In the system 100, a certification authority mechanism 

identity of additional parties that sign. For example, if 55 102 issues an initial primary certificate 110 (one which starts 

only a subscriber mechanism 106 signs, the supple- a new account to certify a customer for authentication) by 

mental assurance maximum per transaction is $125, entering into a contract with the prospective subscriber 

however, if, in addition, a supervisor and two other mechanism 106, gathering the information to be listed in the 

people sign, the supplemental assurance maximum per certificate and obtaining and preserving evidence to docu- 

transaction is $1250. 60 ment satisfaction of the certification authority's duty to 

17. Information regarding the validity of the primary confirm the accuracy of that information. The certification 
certificate 110. The certificate itself specifies its expi- authority mechanism 102 then generally restricts assurance 
ration date, however, the certification authority mecha- on the initial certificate 110 to zero or a low level, and 
nism 102 informs the reliance server 104 of arrange- arranges for secondary certificates 118 to be issued subse- 
ments made with the subscriber mechanism 106 for 65 quently up to a specified assurance limit. The certification 
suspension, revocation, and renewal of the primary authority mechanism 102 then presents the certificate 110 to 
certificate being published. the subscriber mechanism 106 to determine whether, if 
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issued, it will be acceptable, and then forwards it to man- 
agement within the certification authority mechanism 102 
for approval. Once issuance is approved, the certification 
authority mechanism 102 creates the certificate in the pre- 
scribed form and digitally signs it, often using a highly 
secure, distributed private key. Thereupon, the certification 
authority mechanism 102 publishes the certificate with a 
reliance server 104 (if the contract with the subscriber 
mechanism 106 provided for publication). The subscriber 
mechanism 106 then connects with the reliance server 104, 
accepts the certificate with finality, and the reliance server 
104 makes the certificate 110 available on-line. 
l.B.3.2 Suspension Process 

The certification authority mechanism 102 receives and 
logs the request to suspend, noting the identity of the 
requester, the relationship of the requester to the subscriber 
mechanism 106 (if the requester is not the subscriber), the 
date and time of the request, the reason or facts underlying 
the request, and any other relevant information, and duration 
of the requested suspension. The certification authority 
mechanism 102 has no obligation to confirm the accuracy of 
any information provided with the request; however, if the 
contract between the subscriber mechanism 106 and certi- 
fication authority mechanism 102 permits, the certifier may 
investigate, forbear, or limit suspension in circumstances 
which appear to be a prank or fraud. 

The certification authority mechanism 102 generates and 
publishes notice of the suspension 126 with the reliance 
server 104 listed in the certificate as the location where 
notices of suspension or revocation will be posted. 

The reliance server 104 updates the certificate status 
database to indicate the suspension and its duration. If a 
suspension is already in effect, the reliance server 104 alters 
the certificate status database to reflect the information on 
the latest notice. 

The reliance server 104 always reports every suspension 
and every apparent anomaly or irregularity in relation to 
suspension to the certification authority mechanism 102 
which issued the certificate in question. 

The certification authority mechanism 102 updates its 
records to include the notice sent and the acknowledgment 
returned from the reliance server 104. 

The suspension ends automatically when any specified 
duration of the suspension passes. Suspension for an indefi- 
nite period prevents relying parties from closing or carrying 
forward transactions even though the basis for it lacks 
confirmation. The contract between the certification author- 
ity mechanism 102 and subscriber mechanism 106 should 
generally preclude suspension by unconfirmed request for an 
indefinite period. To end a suspension before it is scheduled 
to end in the notice which effected it, a certification authority 
mechanism 102 follows a process similar to the one creating 
the suspension; the certification authority mechanism 102 
receives and logs a request and notifies the reliance server 
104, which updates the certificate status database. 
l.B.3.3 Revocation Process 

A reliance server 104 receiving notice of revocation 
updates the certificate status database to indicate revocation 
of the certificate and returns an acknowledgment and report 
to the publishing certification authority mechanism 102. If 60 
the reliance server 104 receives a duplicate or subsequent 
notice of revocation, it logs the second request but makes no 
other change in the certificate status database, and returns an 
error message. The reliance server 104 always reports every 
revocation and every apparent anomaly or irregularity in 
relation to revocation to the certification authority mecha- 
nism 102 which issued the certificate in question. 



45 



50 



55 



65 



If a standby certificate application (described below) is 
available and has been maintained securely, the revocation 
process explained above can be accomplished automatically 
without sacrificing documentation or shortcutting the certi- 
fication authority's duty to confirm the request to revoke. 
Once a new certificate has been issued based on a standby 
application, the subscriber mechanism 106 can issue a 
digitally signed request for revocation, and its digital sig- 
nature can be confirmed by reference to the certificate newly 
issued based on the standby application. Such revocation 
requests, and they can be processed automatically, however, 
if the subscriber mechanism 106 cannot be re-certified 
through the standby application process, or if for any reason 
the subscriber mechanism 106 has no remaining capability 
of creating a digital signature verifiable by a valid certificate, 
then the certification authority mechanism 102 must use 
some means other than a digital signature to confirm the 
request to revoke, means that usually entail a manual process 
to accomplish the steps outlined above. 
I.B.4. Subscriber Transacts with a Relying Party 

The subscriber mechanism 106 accomplishes a transac- 
tion with a relying party mechanism 108 by forming a 
transaction 112. A transaction is formed by the subscriber 
mechanism 106 digitally signing a document such as a 
contract, letter, purchase order, or the like. There are several 
The transaction 112 includes a data structure termed signed 
information 114 which contains the digital signature and 
information relating to its eventual verification. After digi- 
tally signing the document and attaching the resulting signed 
information data structure 114 to the signed document, the 
subscriber mechanism 106 sends the resulting transaction 
112 (the document and its signed information data structure 
114) to the relying party mechanism 108. The signed infor- 
mation 114 includes the primary certificate 110 issued by the 
certification authority mechanism 102 to the subscriber 
mechanism 106. The subscriber mechanism 106 may also 
include any of the following in the signed information 114 
or attached to the signed information 114: 

1. A signature identifier which uniquely identifies the 
digital signature contained in the signed information 
114 from any other than this subscriber mechanism 
106. 

2. The maximum amount of supplemental assurance that 
the subscriber mechanism 106 permits to be issued for 
the digital signature within the signed information 114 
or the transaction 112 which it authenticates. 

3. A list of relying parties 108 who are permitted (or not 
permitted) to request supplemental assurance for this 
signed information 114. 

4. Alist of relying parties 108 who can (or cannot) request 
supplemental assurance, for which the subscriber 
mechanism 106 has prepaid, for this signed information 
114. 

5. A limit on the number of secondary certificates 118 
and/or the scope of supplemental assurance that can be 
issued for this signed information 114. 

6. A payment advice indicating that the subscriber mecha- 
nism 106 will pay for the supplemental assurance that 
any or a particular relying party will need for the signed 
information 114. 

7. A statement that reliance on the digital signature is 
subject to contract, including a specified certification 
practice statement, which requires a relying party 
mechanism 108 to at least check the current validity of 
the certificate in the records of the reliance server 104 
specified in the certificate 110. 
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The subscriber mechanism 106 can use any combination request one or more secondary certificates 118 containing 

of the above signature parameters to limit the options supplemental assurance from the reliance server 104. This 

available to the relying party mechanism 108 and/or reliance supplemental assurance lessens certain of the relying party's 

server 104 in issuing secondary certificates 118. risks in the transaction and is an engagement by the reliance 

1.B.5 Relying Party Examines the Signed Information 5 server 104 and/or the certification authority mechanism 102 

In determining whether or not to rely on a digital signature that they will bear any losses incurred within the bounds of 

or any other item capable of being assured by a certificate, the supplemental (secondary) assurance provided, 

the relying party 106 receiving the digitally signed docu- If the relying party mechanism 108 determines that the 

ment (with transaction 112) evaluates the risk that the party primary assurance limit stated in the primary certificate 110 

would run if it were to rely on the document without to is less than the assurance that the relying party mechanism 

obtaining further assurances. The degree of assurance 108 desires, the relying party mechanism 108 can request 

required may be prescribed in internal operating procedures supplemental assurance from a reliance server 104. To do so, 

of the relying party mechanism 108 and determined based the relying party mechanism 108 composes a request 116 for 

on a risk study taking into account both a statistical evalu- secondary certificate 118 and sends the request 116 to the 

ation of experience and a technical appraisal of prospective 15 reliance server 104. 

vulnerabilities. The request 116 for secondary certificate 118 sent by a 

The relying party mechanism 108 may well need certifi- relying party mechanism 108 to a reliance server 104 so as 

cation in order for reliance on the on-line transactional to to obtain supplemental assurance has the form shown in 

present an acceptable risk. One or more certificates, either FIG. 5. The request 116 includes the identifier of the primary 

for authentication (digital signatures) or for other purposes, 20 certificate 110 containing the subscriber's public key. 

provide assurance to the relying party mechanism 108 and The primary certificate 110 included in the signed infor- 

lower its risk in relation to issues such as whether a mation data structure 114 lists a reliance server 104 from 

document or transaction is authentic, whether the a pur- which supplemental assurance is to be available, and where 

ported agent actually has the authority to act for another, notice of suspension and/or revocation of the primary cer- 

and, if an obligation is incurred in the transaction, whether 25 tificate 110 is to be posted. The listing of the reliance server 

a trustworthy party, such as the certification authority 104 in the primary certificate 110 may be an actual address, 

mechanism 102, will assure payment or performance. or it may be a proxy or pointer to a network site listing an 

Upon receipt of the transaction 112 including the signed actual address. The relying party mechanism 108 may 

information 114 from the subscriber mechanism 106, the request supplemental assurance from the reliance server 104 

relying party mechanism 108 examines it in order to deter- 30 listed in the certificate, or it may contact another reliance 

mine the nature of the transaction and the amount of reliance server, perhaps one with whom the relying party has an 

it must place on the signed information. Although the signed existing relationship. The request 116 for secondary certifi- 

information 114 and/or the signed document may be cate 118 contains a field in which the relying party can 

encrypted, it is assumed that they are both intended for the indicate the scope of the search to be performed. If the 

relying party mechanism 108 and that the relying party is 35 reliance server 104 to which the relying party mechanism 

capable of decrypting or in some way using the document. 108 sends the request 116 cannot fulfill the request, and if the 

It is also possible that the relying party mechanism 108 is, scope-of-search field permits (by indicating a global scope), 

when necessary, able to decrypt part or all of the primary that reliance server may attempt to locate another reliance 

certificate 110 if the certification authority mechanism 102 server that can fulfill the request. If the scope field permits 

issued it in an encrypted form. Assuming proper access to 40 (i.e., the scope is global) and if the search locates a reliance 

and decryption of the transaction 112 by the relying party server that can fulfill the request, the initial reliance server 

mechanism 108, the information available to the relying can then forward the request to the other reliance server. On 

party may well include, in any given transaction: the other hand, if the scope is set to local, then even if the 

1. the transactional document received; reliance server 104 is unable to fulfill the request it cannot 

2. the signed information 114 data structure and its 45 P^ thc rc( * ucst on t0 ™°^ c \ reliance server, 
contents, including the subscriber's digital signature ^ rec l uest messa S e 116 ako mcludes: 

and certificate 110; 1- a notification address which is where any alerts relating 

3. a monetary amount representing the maximum amount t0 thc ccrtificatc (specified by the message) should be 
of supplemental assurance that the subscriber mecha- cn sent 71115 address could be an electronic address (e.g., 
nism 106 is willing to allocate to the relying party 50 an e " mai1 address ) or some other form of address ; 
mechanism 108 in this transaction; 2. signed attributes (the signed information data structure 

4. payment information indicating whether the subscriber and 

mechanism 106 will pay for a secondary certificate 118 3. a request type specifying the type of assurance being 

providing supplemental assurance to the relying party 55 requested (described below). 

mechanism 108; If the relying party's request for supplemental assurance 

5. any restrictions imposed by the subscriber mechanism * granted, this is stated in a secondary certificate 118. A 
106 in relation to services to be provided by the reliance secondary certificate 118 is a message issued and digitally 
server 104. These restrictions include listing which si S ned b y a reliance server 104 or other certification author- 
relying parties may receive secondary certificates 118 60 itv mechanism 102. A secondary certificate 118 can certify 
for the transaction 112' and or assu re any fact, status, or obligation material to a 

6. additional information such as referenced, linked, or transaction, including the following: 

enveloped documents or data, that the subscriber 1* The accuracy of another certificate, such as an authen- 

mechanism 106 has attached to the content information tication certificate, which identifies a person with a 

and/or signed information 114. 65 public key. 

Based on this and any other available information, the 2. The authenticity of another certificate, by attesting to 

relying party mechanism 108 determines whether or not to the fact that the digital signature on other certificate has 
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been verified by reference to a chain of certificates 
terminating in a root certifier. 

3. The validity of another certificate, by determining (if 
passible and among other things) where notice of 
revocation or suspension is to be posted and checking 
that location. 

4. The grant by a specified principal of authority to a 
specified agent. 

5. The accreditation of a person by a licensing or profes- 
sional body. 

6. The existence and/or good standing of a person who is 
a juridical or artificial entity. 

7. The performance of an obligation. (A certificate of this 
type is a guaranty of performance or a letter of credit 
assuring payment or satisfaction of an obligation.) 

The validity of a secondary certificate 118 is generally 
limited in relation to a specified time and usually up to a 
specified amount, and may also be limited to a specified 
relying party mechanism 108, digital signature or 
transaction, a specified EDI transaction type or transaction 
set, or according to other criteria as agreed by the reliance 
server 104 and relying party mechanism 108. If provision of 
supplemental assurance limits the availability of further 
supplemental assurance for the subscriber mechanism 106, 
the subscriber may also limit the amount of secondary 
assurance provided in a given transaction. The signed infor- 
mation data structure 114 created by the subscriber mecha- 
nism 106 in signing the document (and incorporated into a 
request message 116 as "signed attributes") includes several 
fields digitally signed by the subscriber mechanism 106 and 
limiting the availability of supplemental assurance for the 
transaction to a specified maximum assurance limit. The 
relying party mechanism 108, in requesting supplemental 
assurance, specifies a desired amount and a minimum 
acceptable amount, and the reliance server 104 provides 
supplemental assurance in the desired amount if it is less 
than the maximum specified by the subscriber mechanism 
106, and if it is not, then in the maximum specified by the 
subscriber mechanism 106 if it exceeds the minimum 
acceptable amount indicated by the relying party. If the 
maximum specified by the subscriber mechanism 106 is less 
than the minimum amount acceptable to the relying party 
mechanism 108, then the reliance server 104 returns an error 
message inviting the relying party to take the issue up with 
the subscriber mechanism 106. 

1.B.6 Reliance server Processes Relying Party's Request 

Upon receipt of a request 116 for secondary certificate 
118, the reliance server 104 checks whether the relying party 
mechanism 108 has been enrolled in the system by verifying 
the relying party's digital signature using the public key 
linked to a particular contract form and an event in which the 
relying party assented to the contract. If a record of the 
relying party's enrollment cannot be found, then the reliance 
server makes a contractual offer to the relying party, and, if 
the relying party accepts it, creates a certificate for the 
relying party, which links the contract to a public key. Any 
information obtained about the relying party's identity is 
unconfirmed and is kept on an as-is basis. 

If the relying party is enrolled with the reliance server 
104, the reliance server fulfills the relying party's request by 
doing the following, depending on what the relying party 
requested: 

l.B.6.1 Relying party requested assurance of the accuracy of 
another certificate 

If the relying party mechanism 108 requested assurance of 
the accuracy of another certificate, the reliance server 104 
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checks the current validity of the certificate and its authen- 
ticity (by verifying its digital signature along a chain of 
certificates), and checks whether the requested assurance is 
within the secondary assurance parameters. If, in light of 

5 validity, authenticity, and the secondary assurance 
parameters, further assurance can be provided, the reliance 
server 104 issues a secondary certificate 118 attesting to the 
accuracy of the designated certificate. 
l.B.6.2 Relying party requested assurance of the authentic- 

10 ity of another certificate 

If the relying party mechanism 108 requested assurance of 
the authenticity of another certificate, the reliance server 
verifies the digital signature on the certificate by reference to 
the public key listed in another certificate, and then verifies 

15 the digital signature on that other certificate. This process is 
repeated along a chain of certificates ending with one issued 
by a root certifier (certification authority, see, e.g., Root CA 
in FIG. 2). The reliance server 104 also checks each such 
certificate to determine whether it is valid. If all digital 

20 signatures are verified by reference to public keys listed in 
valid certificates, the reliance server issues a secondary 
certificate 118 attesting to the authenticity of the other 
certificate. 

l.B.6.3 Relying party requested assurance of the validity of 

25 another certificate 

If the relying party mechanism 108 requested assurance of 
the validity of another certificate, the reliance server deter- 
mines from the certificate where validity information is to be 
posted. If the reliance server 104 is the site of the validity 

30 information, it checks its certificate validity database, If that 
database indicates that the certificate has been issued by its 
certification authority mechanism 102, accepted by its sub- 
scriber mechanism 106, but is not suspended, revoked, or 
expired, then the reliance server issues a secondary certifi- 

35 cate 118 attesting to the current validity of the certificate. 
l.B.6.4 Relying party requested assurance of an agent's 
authority 

If the relying party mechanism 108 requested assurance of 
an agent's authority, the reliance server 104 returns a power 
40 of attorney or a similar grant or documentation of agency, 
with an enveloping secondary certificate attesting to authen- 
ticity. 

l.B.6,5 Relying party requested assurance of person's 
accreditation 

45 If the relying party mechanism 108 requested assurance of 
person's accreditation, the reliance server 104 returns a 
statement by a licensing or professional body regarding the 
person's accreditation, with an enveloping secondary cer- 
tificate 118 attesting to the statement's authenticity. The 

so statement of accreditation can be a certification authority 
disclosure record, e.g., as described in the Utah Act and the 
administrative rules based thereon. 

l.B.6.6 Relying party requested assurance of existence and/ 
or good standing of entity 

55 If the relying party mechanism 108 requested assurance of 
the existence and/or good standing of a juridical or artificial 
entity, the reliance server 104 returns a statement by the 
public office in which the entity is incorporated or otherwise 
created indicating that the entity exists, is in good standing, 

60 and/or is otherwise qualified to conduct business. The state- 
ment is enclosed in a secondary certificate 118 attesting to 
the statement's authenticity. 

l.B.6,7 Relying party requested assurance of the perfor- 
mance of an obligation 
65 If the relying party mechanism 108 requested assurance of 
the performance of an obligation, the reliance server 104 
issues a letter of credit or other guaranty or assurance of 
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payment, if credit is available and appropriate arrangements 
have been made with the subscriber mechanism 106. 

The reliance server 104 performs the above actions, 
including the issuance of secondary certificates 118, auto- 
matically based on previously specified criteria. 5 

Performance of the above actions can fail for a number of 
reasons, in addition to system malfunction or down time. If 
possible, when a request cannot be fulfilled, the reliance 
server 104 returns to the relying party mechanism 108 an 
error message, such as: 30 

Certificate expired 

The certificate has expired according to its own expiration 
field. 

Certificate revoked 

Notice of revocation had been posted at the location 15 
specified in the certificate, or was otherwise found by the 
requested search. The message includes the date of revoca- 
tion. 

Certificate suspended 

Notice of suspension had been posted at the location 2 o 
specified in the certificate, or was otherwise found by the 
requested search. Further information about the duration of 
the suspension, the grounds for or cause of it, and the event 
triggering the suspension is provided where available. 

Search Failed 25 

The certificate could not be found. 

Multiple certificates found 

TWo certificates were found identified by the same, sup- 
posedly unique identifier. This error indicates a defect in the 
reliance server system. 30 

To sign and issue the secondary certificate 118, the 
reliance server 104 may send it (as an intermediate trans- 
actional certificate) to certain other parties 124a-124n, per- 
haps including any of the following: 

a. An underwriter mechanism 124a which insures or 35 
otherwise aids in bearing the risk of certification; and 

b. A fail-safe database, which is a clone of the reliance 
server's database, and which assures that any tamper- 
ing with the reliance server's database is detected. 

The other parties 124a-124« execute functions which 40 
result in a digital signature on the secondary certificate 118. 
Generally, the signing technology used is multi-step signing, 
which is disclosed and described is U.S. patent application 
Ser. No. 08/462,430, titled "Multi-step Digital Signature 
Method and System" to Sudia, which is hereby fully incor- 45 
porated herein by reference. 

1.B.7 Reliance server Maintains History of Transactions 

The reliance server 104 and/or its agent(s) maintains a 
history of all secondary certificates that are issued. This 
information is useful in determining anomalies in the use of 50 
certificates and in determining whether secondary or 
renewal certificates should be issued. 
1.B.8 Reliance server Account Statements to Subscriber 
Subscriber Account Statements 

Periodically, while the initial primary certificate 110 or 55 
one of its replacements is valid, the reliance server 104 
which is designated to provide assurance for that certificate 
sends electronic reports of account status to the subscriber 
mechanism 106. The subscriber receives these account sta- 
tus reports as often as the subscriber wishes but preferably 60 
no less frequently than every month. One option for speci- 
fying an account status update interval, whereby an update 
report is provided to the subscriber mechanism 106 when- 
ever it sends another request to a reliance server 104. This 
option causes the reliance server to tack on an account 65 
statement whenever the user obtains other information from 
the reliance server 104 where the certificate is published. 
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This information includes, e.g., a report on the current 
validity of another person's certificate or a secondary cer- 
tificate for increased assurance. 

Account statements need not appear as separate messages 
to the subscriber mechanism 106, unless the subscriber 
chooses to view them as such when they arrive. Rather, 
account statements update information accumulated by the 
subscriber mechanism 106 in a local database. The infor- 
mation received in account statements can be sorted and 
viewed on a per-signature or chronological basis, with the 
chronology determined by either the date on which a rel- 
evant digital signature was created or when a particular 
account statement was received. 

Account statements report the following information to 
the subscriber mechanism 106: 

1. Validity of subscriber's (time-based) certificates: list all 
(time-based) certificates issued to the subscriber 
mechanism 106, starting with the most recent, and 
indicate which is currently valid and when invalidated 
certificates were suspended or revoked, or when they 
expired. 

2. Secondary certificates issued: When the reliance server 
104 issues a secondary certificate, the reliance server 
104 reports the issuance of that secondary certificate in 
the next account statement. The statement indicates 
details such as amount, the name of the person who 
requested the secondary certificate (if identified), and 
the name of the guarantee if the secondary certificate 
includes supplemental assurance. The subscriber 
mechanism 106 can use this report to determine 
whether a compromise has occurred, since unantici- 
pated usage of assurance, especially by strangers, could 
in some circumstances indicate that forged or at least 
unexpected digital signatures have been created. Digi- 
tal signatures are numbered and time-stamped in the 
system 100 in order to facilitate the subscriber's review 
of assurance usage. 

3. Assurance balance: The assurance portion of the 
account statement also indicates the applicable assur- 
ance limits and how much assurance has been issued in 
relation to each limit. The subscriber mechanism 106 
correlates this information with digital signatures that 
have been created, including digital signatures for 
which no secondary certificates have been requested. 
Such digital signatures may present an outstanding, 
unmet need for assurance, and the subscriber mecha- 
nism 106 may wish to assess whether such an unmet 
need can be met by the balance of assurance remaining. 

4. Assurance termination: When a assurance guaranty 
expires or deadline (if any) for filing claims on a 
secondary certificate passes, the assurance balance for 
the primary certificate is increased accordingly. The 
account statement reflects those increases and reports 
when assurance is scheduled to terminate. 

Account statements may also return information regard- 
ing other electronic services such as other account transac- 
tions and balances, and information on other financial and 
commercial services. The subscriber mechanism 106 cumu- 
lates all information reported in periodic account statements 
until the subscriber mechanism 106 deletes or archives the 
information. 

Account statements return to the subscriber mechanism 
106 the information necessary to discover and resolve 
problems, and thereby help manage the risk of rendering 
certification and assurance services. A bank's liability to its 
customer is lessened if the customer's failure to discover and 
take corrective action contributed to the problem. 
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Incident Tracking and Account Histories 1.B.9 Billing and Payment 

Besides account statements returned to subscribers, the The digital messages described above (transaction 112 
certification authority mechanism 102 issuing a primary and request 116) include price and payment authorization 
certificate (including an initial primary certificate) and the information to enable costs to be allocated and paid accord- 
reliance server 104 issuing secondary certificates based on s mg l0 contracts between the various parties. The system 100 
that primary certificate track the history of the primary ^ flexible in enabling costs to be passed through to other 
certificate and its dependent secondary certificates, and note parties and allocated as they may decide. In particular, the 
all incidents related thereto that arise. Incidents are events or fccs for publicatioD 0 f certificates or notices of revocation by 
belatedly acquired information relevant to issuance of the the reUance 104 can be id b the certification 
initial certificate that may indicate difficulties or problems w authod m qt ^ mechanism 106 , and fees for 
with the account or the primary certificate, or may in some , ' u ju*u u u u 

. . * u * •? c ■ c *• secondary certificates can be paid by the subscriber mecha- 

mstances prove to be innocuous it further into rmation were . , . ^ L • mo n i ■ 

available. The seriousness of incidents varies according to ™f ™ 6 ™ f"? mechanism 108 Relying parties 

the degree to which a likely problem can be inferred. ^ subscribers can obtain a pricing schedule automatically 

Incidents relating directly to certification for authentication, b y 10 a rellance 104 

and their relative seriousness on a scale of 1 through 5, 15 EXAMPLE 
include; 

1. Claim filed (level 5): A relying party files a claim based Suppose, for example, that a certification authority, 
on a secondary certificate, or makes any demand or Cedric, issues a certificate, Cert-1, to a subscriber named 
initiates a lawsuit based on a certificate issued in the Susan as provided in a contract with Susan. Cert-1 specifies 
system 100. 20 that it is to be used with a "Type C" reliance server system, 

2. Fraud or similar allegations (level 5): A party in a civil and also specifies its public key encrypted. Cert-1 specifies 
or criminal proceeding, arbitration, or other dispute or a assurance limit of $0; in other words, no reliance is 
investigation alleges that the subscriber mechanism permitted on Cert-1. Cedric provides a copy of Cert-1 to 
106 committed any significant form of fraud, subscriber Susan, and she accepts it. Since Cert-1 is not, in 
misrepresentation, or other false statement. 25 itself, reliable in view of its $0 assurance limit, its essential 

3. Suspension or revocation requested (level 1): The utility is to direct relying parties to a reliance server. As the 
subscriber mechanism 106 asks a certification authority contract with Susan provides, Cedric publishes Cert-1 with 
mechanism 102 to suspend a time-based certificate. Margaret, a reliance server. 

Repeated suspensions or revocations may indicate a Margaret establishes a new certification account and an 

lack of desirable care in maintaining the security of the 30 entry in her certificate validity database for Susan's 

private key. certificate, and sets parameters to govern the automatic 

An account history cumulates as much information as issuance of secondary certificates based on information 

possible about a single subscriber's certification or certifi- provided by Cedric. Margaret thereupon sends an initial 

cations. The information is gathered for multiple primary message to Susan to inform her that the publication is 

certificate certificates and other certifications for the same 35 completed and she can expect to receive periodic account 

subscriber mechanism 106 over time and across different statements. 

certification authorities and reliance servers. The inform a- Susan sends an offer to Perry to buy certain goods for 

tion is also obtained from reliance servers and from external $10,000. Susan digitally signs her offer and attaches a copy 

sources such as courts. ^ the keyless version of Cert-1. 

Both certification authorities issuing a primary certificates Xo determine whether Susan's offer is genuine, Perry runs 

and reliance servers keep track of this information and a verification function, which reports that the digital signa- 

exchange incident report messages to update each other and turc app ears to be verifiable by the public key in the 

a central account history database under the direction of the certificate, but that the certificate has a $0 assurance limit 

root certification authority. Information is retained online ^ and SU ppi eme ntal assurance is available from Margaret, 

and archived as prescribed in an account history retention p errv sen j s a re q Ues t to Margaret for supplemental assur- 

schedule specified for the system 100. ance for the certificate in an amount not less than $10,000. 

The information exchanged between the reliance server Margaret's system responds with a secondary certificate, 

104 and the certification authority mechanism 102 includes: Cert-2, which envelopes Cert-1 and specifies that its accu- 

1. certificate revocation lists (CRLs) 128; 5Q racy arl d reliability are assured in the amount of $10,000, in 

2. certificate suspension or revocation notices 126; relation to Perry and his assignees only and for the digital 

3. issued certificate lists 130; signature on Susan's offer only. Because Susan did not 

4. issued assurance reports 132; authorize payment for Cert-2 from her account, Perry pays 

5. certificate exception reports 134; and Margaret's fee for issuance of the secondary certificate. 

6. assurance exceeded reports 136. 55 To issue the secondary certificate that Perry received, 
Incident reports and records cumulated or derived from Margaret's system parsed and analyzed his request, checked 

them may not be disclosed to anyone other than a certifi- the validity of Cert-1, checked its authenticity by verifying 

cation authority mechanism 102 issuing in good faith a its digital signature and other digital signatures along the 

certificate to the subscriber mechanism 106 which is the certificate authenticity chain, and checked the requested 

subject of the incident, such a certification authority's parent 60 amount of supplemental assurance in relation to the param- 

certification authority, a reliance server 104 issuing a sec- eters specified for Susan's certification account. After all 

ondary certificate on the subject subscriber's account, and checks returned affirmative results, Margaret's system 

the root certification authority. In addition, account history issued Cert-2. 

information is subject to legal data protection requirements If Perry had been concerned about Susan's authority to 

that may further limit availability in some legal systems or 65 make the offer on behalf of someone else, or about Susan's 

require disclosure of account history information to the ability to pay the $10,000 for the widgets, Perry could have 

subscriber mechanism 106. obtained additional supplemental assurance. He could have 
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obtained a copy of a power of attorney authorizing Susan to 
make the offer, and a letter of credit from Margaret (or her 
bank, if Margaret is not a bank) assuring payment of the 
price. Supplemental certificates need not be requested when 
a digital signature is verified. Obtaining a letter of credit, for 
example, may be more timely after Perry sends his digitally 
signed acceptance of Susan's offer to her. 
1.B.10 Suspending and Revoking Certificates 

Suspension and revocation are the means by which a 
subscriber mechanism 106 and certification authority 
mechanism 102 can relieve themselves of the responsibili- 
ties and risks of a certificate before it expires. Revocation 
permanently ends the validity of a certificate, and suspen- 
sion interrupts it temporarily. While the certificate is invalid, 
the subscriber mechanism 106 is not under a legal duty to 
safeguard the private key, the representations of the certifi- 
cation authority mechanism 102 in the certificate have no 
further effect, and reliance on the certificate is almost 
certainly unreasonable. 

However, notice of suspension or revocation need not 
ordinarily include identification of the subscriber mecha- 
nism 106, since the certificate can be identified by its serial 
number. In the system 100, publication at the location 
specified in the certificate directs the notice to a reliance 
server 104. Which reliance server 104 receives and pro- 
cesses an incoming notice depends on the location specified 
in the certificate as the location where notice of suspension 
or revocation will be posted. 
l.B.ll Suspension Process 

Each reliance server 104 maintains a certificate validity 
database, preferably a high-speed relational database, which 
accumulates and makes available on-line all notices of 
suspension and revocation received from certification 
authorities. A user may browse or query the certificate status 
database manually to search for notice of a particular cer- 
tificate's suspension or revocation, but to gain a higher level 
of efficiency and assurance, a user can obtain a certificate 
indicating that no notice of suspension or revocation is on 
file. In other words, on request, a reliance server 104 will 
issue automatically and at high speed a certificate affirming 
that the accumulated notices published with the reliance 
server 104 as of a certain date and time do not include a 
notice of revocation of a specified certificate, and that the 
accumulated notices do not include a notice of suspension 
which is in effect as of that date and time. 

The certification authority mechanism 102 receives and 
logs the request to suspend, noting the identity of the 
requester, the relationship of the requester to the subscriber 
mechanism 106 (if the requester is not the subscriber), the 
date and time of the request, the reason or facts underlying 
the request, and any other relevant information, and duration 
of the requested suspension. The certification authority 
mechanism 102 has no obligation to confirm the accuracy of 
any information provided with the request; however, if the 
contract between the subscriber mechanism 106 and certi- 
fication authority mechanism 102 permits, the certifier may 
investigate, forbear, or limit suspension in circumstances 
which appear to be a prank or fraud. 

The certification authority mechanism 102 generates and 
publishes notice of the suspension 126 with the reliance 
server 104 listed in the certificate as the location where 
notices of suspension or revocation will be posted. 

The reliance server 104 updates the certificate status 
database to indicate the suspension and its duration. If a 
suspension is already in effect, the reliance server 104 alters 
the certificate status database to reflect the information on 
the latest notice. 
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The reliance server 104 always reports every suspension 
and every apparent anomaly or irregularity in relation to 
suspension to the certification authority mechanism 102 
which issued the certificate in question. 

5 The certification authority mechanism 102 updates its 
records to include the notice sent and the acknowledgment 
returned from the reliance server 104. 

The suspension ends automatically when any specified 
duration of the suspension passes. Suspension for an indefi- 

10 nite period prevents relying parties from closing or carrying 
forward transactions even though the basis for it lacks 
confirmation. The contract between the certification author- 
ity mechanism 102 and subscriber mechanism 106 should 
generally preclude suspension by unconfirmed request for an 

15 indefinite period. To end a suspension before it is scheduled 
to end in the notice which effected it, a certification authority 
mechanism 102 follows a process similar to the one creating 
the suspension; the certification authority mechanism 102 
receives and logs a request and notifies the reliance server 

20 104, which updates the certificate status database. 
1.B.12 Revocation 

A reliance server 104 receiving notice of revocation 
updates the certificate status database to indicate revocation 
of the certificate and returns an acknowledgment and report 

25 to the publishing certification authority mechanism 102. If 
the reliance server 104 receives a duplicate or subsequent 
notice of revocation, it logs the second request but makes no 
other change in the certificate status database, and returns an 
error message. The reliance server 104 always reports every 

30 revocation and every apparent anomaly or irregularity in 
relation to revocation to the certification authority mecha- 
nism 102 which issued the certificate in question. 

If a standby certificate application (described below) is 
available and has been maintained securely, the revocation 

35 process explained above can be accomplished automatically 
without sacrificing documentation or shortcutting the certi- 
fication authority's duty to confirm the request to revoke. 
Once a new certificate has been issued based on a standby 
application, the subscriber mechanism 106 can issue a 

40 digitally signed request for revocation, and its digital sig- 
nature can be confirmed by reference to the certificate newly 
issued based on the standby application. Such revocation 
requests, and they can be processed automatically, however, 
if the subscriber mechanism 106 cannot be re-certified 

45 through the standby application process, or if for any reason 
the subscriber mechanism 106 has no remaining capability 
of creating a digital signature verifiable by a valid certificate, 
then the certification authority mechanism 102 must use 
some means other than a digital signature to confirm the 

50 request to revoke, means that usually entail a manual process 
to accomplish the steps outlined above. 
l.B.12.1 Suspending and Revoking Secondary Certificates 
Once a reliance server 104 has issued a secondary 
certificate, it can suspend or revoke the certificate in the 

55 manner described above for a time-based certificate. A 
subscriber mechanism 106 nearly always suspends or 
revokes the primary certificate because the most common 
reason for the subscriber to suspend or revoke, a compro- 
mise of the security of the private key, affects the entire 

60 primary certificate and all assurance based on it. A reliance 
server 104 immediately and automatically revokes all sec- 
ondary certificates issued based on a primary certificate, but 
such revocation usually comes too late. 

Generally the relying party requests a secondary certifi- 

65 cate immediately before relying on a digital signature. Once 
a relying party receives the secondary certificate and relies, 
it is too late for the revocation of the secondary certificate, 
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or of the primary certificate, for that matter, to have any 
significant effect. It may prevent further reliance by the same 
or other parties, but the rights of the relying party have 
become vested at that point, and those rights can be 
assigned, even though the underlying digital signature 5 
became unreliable thereafter. 

Moreover, issuing a secondary certificate and revoking it 
immediately thereafter could well be viewed as entrapping 
or failing to deal in good faith with the relying party. The 
rules of the system 100 and the contract with the relying jq 
party prevent a reliance server 104 from revoking a certifi- 
cate within five minutes of its issuance. 

As a practical matter, therefore, suspension or revocation 
of a secondary certificate is not likely come in time to save 
a subscriber mechanism 106 or certification authority from 35 
a loss. Thus, while secondary certificates can be and are 
revoked in the system 100, suspension and revocation of the 
primary certificate are the principal means preventing harm 
based on a certification gone awry. 

1.B.13 Expiration and Replacement of a Time-Based Cer- 2 o 
tificate 

A time-based certificate expires at the end of the validity 
period specified therein. Expiration occurs automatically, 
without an affirmative act on anyone's part at the time 
specified for expiration in the time -based certificate. To 2 s 
provide complete information to relying parties about the 
status of a certificate, information on expiration is included 
in the certificate status database. 

An expired time-based certificate can be replaced through 
issuance and acceptance of a new certificate identifying the 30 
same subscriber mechanism 106 but listing a new public 
key. The cryptographic key pair certified in a time -based 
certificate has a limited lifetime since technological 
improvements may render the security of the key pair 
vulnerable to an attack facilitated by the availability of an 35 
accumulating body of ciphertext. An old, expired certificate 
should therefore not be reissued as- is with its old public key. 

The process for reissuing a replacement certificate to the 
same subscriber mechanism 106 is essentially the same as 
for issuing an initial certificate, except that confirmation is 40 
easier, because the evidence obtained to confirm information 
in the previous certificate can aid in confirming the infor- 
mation in the new certificate. Stale information may need 
updating, and a certification authority mechanism 102 
should always be alert to indications of inaccuracies, but 45 
building on an existing information base with an accumu- 
lating account history makes re -issuance of a subsequent 
certificate a simpler and less costly and risky process for the 
certification authority mechanism 102. Whereas issuing a 
new certificate with adequate confirmation may be difficult 50 
or risky without an in -person contact, re-issuance of a 
replacement certificate in a trouble-free account and without 
a greatly increased assurance level could well be done by 
telephone or by a digitally signed request before the expi- 
ration of the old certificate. 55 
1.B.14 Automatic Replacement of a Time-Based Certificate 

Since replacement of a time-based certificate lends itself 
to automation better than initial issuance, some time-based 
certificates may have rather short validity periods but be 
automatically replaceable. A short initial validity period with 60 
automatic replaceability can accommodate, in particular: 

Experimenters: Some subscribers may be uncertain 
whether digital signatures and certification will prove 
valuable or serve their needs. 

Nervous subscribers: A brief validity period alleviates 65 
concern about retaining a private key securely for long 
periods or other risks of electronic commerce, but 
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allows the subscriber mechanism 106 to extend validity 
in a convenient manner, perhaps as comfort increases. 
Lack of history: Potential subscribers who are new to the 
community or appear to have little relevant history 
present a greater risk than better known applicants. Use 
of short-term, replaceable certificates gives a relatively 
unknown subscriber mechanism 106 a chance to estab- 
lish a track record. 
Instability: Certificates listing information that is likely to 
require updating can be made to expire soon so that 
their subscribers can replace them and update the 
certified information. 
Moreover, and perhaps most importantly, a short validity 
period limits the risk of loss due to a compromise of a private 
key. The more frequently a subscriber's digital signature 
capability (including the private key) is regenerated, the less 
the risk of failing to safeguard any particular private key, 
since the lifetime of the corresponding certificate is shorter. 

However, although automatic replacement is often 
advantageous, a certification authority mechanism 102 
should not permit automatic replacement of a time -based 
certificate in all possible circumstances. Whether or not to 
permit automatic replacement and under what circumstances 
is to some extent left to the discretion of a the certification 
authority mechanism 102 issuing a certificate, in coopera- 
tion with the reliance server 104 and assurance underwriter, 
who are affected by replacements in relation to assurance. 
For each subscriber mechanism 106 account, the certifica- 
tion authority mechanism 102 includes an field indicating 
the number of times the time-based certificate may be 
replaced automatically, and the value in this field is decre- 
mented whenever an automatic replacement process suc- 
ceeds. If the field is zero, the certification authority mecha- 
nism 102 does not initiate the automatic replacement 
process. The value is set initially by the certification author- 
ity mechanism 102 issuing the certificate being replaced. 
The discretion (of the certification authority mechanism 102 
as to whether and under what circumstances to permit 
automatic certificate replacement) is limited in the system 
100, which precludes automatic replacement where: 

Change in identifying information: Certain fields in the 
reliance servers and certification authorities databases, 
particularly fields containing information identifying 
the subscriber mechanism 106, cannot be updated by an 
automatic certificate replacement process. If identify- 
ing information in the subscriber's application does not 
match what is already in the reliance server database, 
the application is routed to the issuing certification 
authority mechanism 102 and from there to a registrar, 
who can contact the subscriber mechanism 106 to 
confirm the change in identifying information. 
Increase in assurance: A certification authority mecha- 
nism 102 or reliance server 104 (in cooperation with a 
assurance underwriter) may refuse to increase assur- 
ance at all in an automatically replaced certificate, or 
may restrict the rate of increase by means of automatic 
replacement in accordance with the soft and hard 
ceilings and other requirements specified for the assur- 
ance limits. 

No authentication capability: Issuance of a replacement 
certificate must be based on adequate documentation of 
the continuing accuracy of the information to be listed 
in the new certificate and of the subscriber's acceptance 
of the new certificate. To replace a certificate 
electronically, a subscriber mechanism 106 must 
authenticate an application and acceptance. If the cer- 
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tificate to be replaced is no longer valid and no other 
valid authentication certificate or standby application 
for certificate replacement (described below) exists for 
the subscriber mechanism 106, the subscriber can no 
longer replace the certificate by electronic means. 
Troubled history: The account history records of the 
certification authority mechanism 102, which are cor- 
related with reliance servers and a central repository, 
list incidents rising to a level of seriousness specified in 
the certification authorities contract with the reliance 
server 104, In other words, the certification authority 
mechanism 102 and reliance server 104 agree that 
automatic replacements will not be processed if inci- 
dents are found having a certain level of gravity. 
The reliance server 104 keeps track of the number of 
times an initial certificate may be automatically replaced, a 
number that maybe zero. Like is suspension and revocation, 
the automatic replaceability of the certificate is determined 
initially by the certification authority mechanism 102 issu- 
ing it and is published in the reliance server 104 and made 
available from there to end users, including the subscriber 
mechanism 106 receiving account statements. If a certificate 
cannot be automatically replaced, its subscriber mechanism 
106 can apply to have a new certificate issued as described 
above. 

To replace a time -based certificate automatically, a sub- 
scriber mechanism 106, certification authority mechanism 
102, and reliance server 104 interact as follows: 

The subscriber initiates the replacement process: The 
subscriber mechanism 106 keeps track of the validity of 
the subscriber's certificate and chooses to replace it 
when it is about to expire. The subscriber mechanism 
106 learns of revocation or suspension of the certificate 
through account statements from the reliance server 
104, and then initiates replacement using a standby 
application. Prompts can be given, at the subscriber's 
option, when the subscriber mechanism 106 uses the 
system, for example, when the subscriber mechanism 
106 attempts to create a digital signature without a 
valid certificate by which the signature can be verified. 

The subscriber applies for a new certificate: Once the 
subscriber mechanism 106 triggers the replacement 
process, it creates a new application listing the infor- 
mation in the old certificate. The subscriber mechanism 
106 reviews the application form and makes any 
needed changes, then generates a new key pair and 
includes the public key and a sample digital signature 
in the application. The subscriber mechanism 106 then 
digitally signs the application using the private key of 
the subscriber's old certificate, if it is still valid. Since 
the application includes and presents to the subscriber 
mechanism 106 all information that will be listed in the 
certificate, the subscriber mechanism 106 also accepts 
the certificate to be issued in the application. The 
subscriber mechanism 106 then sends the replacement 
application to either the certification authority mecha- 
nism 102 which issued the certificate to be replaced or 
the reliance server 104 named in that certificate, 
depending on the contract between them. The place to 
apply for a replacement is stored in the subscriber's 
system when the subscriber mechanism 106 accepts the 
certificate and obtains an initial account statement. 

The certification authority mechanism 102 or reliance 
server 104 issues the new certificate: The certification 
authority mechanism 102 checks the application, and, if 
it can be automatically processed, creates a new cer- 
tificate from it and digitally signs it. If the certification 
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authority mechanism 102 issues the certificate, it for- 
wards it for publication with the reliance server 104, all 
without human intervention. If the reliance server 104 
issues the certificate, it notifies the certification author- 
ity mechanism 102 which issued the replaced 
certificate, if required by contract with that certification 
authority mechanism 102. If automatic replacement is 
not permitted, then the application for replacement is 
forwarded for processing by a registrar. 
The reliance server 104 publishes the certificate and 
updates the subscriber's certificate status database record to 
indicate a new primary certificate and its new expiration 
date, and adjusts the Assurance limits according to the 
contract between the reliance server 104 and the certification 
authority mechanism 102 issuing the primary certificate. 
The reliance server 104 acknowledges receipt and reports 
updating to the certification authority mechanism 102 pub- 
lishing the certificate, and updates the subscriber's records 
kept by the system when issuing the next account statement. 

Automatic replacement is based ultimately on the time- 
based certificate being replaced, the assurance limits and 
their monitoring, and the account history records accumu- 
lated since enrollment of the subscriber mechanism 106. It 
makes the most of those processes and, in effect, prevents 
termination or interruption of a certification account when 
termination or interruption does not appear to be warranted 
in light of accumulated evidence. However, since the auto- 
matic replacement process overrides the effect of certificate 
expiration, suspension and revocation of a certificate 
become all the more important. 

1.B.15 Automatic Replacement Using a Standby Applica- 
tion 

A certificate can be replaced automatically only if its 
subscriber mechanism 106 can electronically and reliably 
authenticate the information to be listed in the new certifi- 
cate and accept it, since the certification authority mecha- 
nism 102 issuing the replacement must document confirma- 
tion of the information in the new certificate and the 
acceptance of the new certificate. If the subscriber mecha- 
nism 106 has no valid certificate remaining, the subscriber 
can no longer create a sufficiently reliable digital signature. 

To relieve this predicament, the subscriber mechanism 
106 stores a digitally signed standby application for certi- 
fication of a new key pair, an application which can be used 
to obtain a new certificate if critical, digitally signed infor- 
mation in the application does not need to be updated. When 
a subscriber mechanism 106 applies for a new initial 
certificate, the system creates two applications. One is 
forwarded to a certification authority mechanism 102 for 
issuance of a new certificate, and the other is crypto graphi- 
cally sealed and stored in the subscriber's system as a 
standby application. The standby application contains its 
own public key different from any other on the subscriber's 
system, and the corresponding private key is stored in a safe 
place in the subscriber's system. 

A standby application is digitally signed by a private key 
which is destroyed immediately after it is used to sign the 
standby application. The corresponding public key is 
included in a transactional certificate valid only for the 
standby application and forwarded to the certification 
authority mechanism 102 along with the main application. 
The certification authority mechanism 102 keeps the trans- 
actional certificate on file in case the subscriber mechanism 
106 sends the standby application which the certification 
authority mechanism 102 will need to verify using the public 
key in the transactional certificate. 

If the subscriber mechanism 106 cannot replace a certifi- 
cate by means of a regular application digitally signed by an 



11/12/2003, EAST Version: 1.4.1 



5,9( 

31 

existing and valid digital signature capability, the subscriber 
mechanism 106 can use the standby application. The sub- 
scriber mechanism 106 detects that no valid certificate is 
outstanding and ascertainable, so it uses the standby 
certificate, provided that no critical information identifying 
the subscriber mechanism 106 has changed. If the identify- 
ing information in the standby certificate is still accurate, the 
subscriber mechanism 106 sends the standby application to 
the subscriber's certification authority mechanism 102, 
which verifies the digital signature on the application by 
reference to the transactional certificate kept on file for such 
situations. The certification authority mechanism 102 then 
issues a new time-based certificate listing the public key 
indicated in the standby application. The subscriber mecha- 
nism 106 then unwraps the private key stored away for use 
in the event that a certificate is issued based on the standby 
application. 

Once the subscriber mechanism 106 has obtained a new 
certificate using the standby application, the subscriber 
mechanism 106 can send a new regular application to 
replace the subscriber's certificate at any time before it 
expires. The process for creating and sending the regular 
application creates and stores away securely a new standby 
application and standby private key. 

The event triggering issuance of a new certificate based 
on a standby application is the sending of the standby 
application to the certification authority mechanism 102. 
The certificate issued in response to the application always 
lists as subscriber mechanism 106 the person identified in 
issuing a previous certificate in order to minimize the chance 
of issuing a certificate to an impostor. Sending a standby 
application does not by itself affect any other outstanding 
certificate, although the subscriber mechanism 106 may use 
the new certificate to make a request to revoke another 
certificate capable of being authenticated. 

The contract between a subscriber mechanism 106 and a 
certification authority mechanism 102 may limit or preclude 
use of a standby application. However, use of standby 
applications and automatic replacement will probably prove 
convenient for most subscribers and make possible shorter 
validity periods on time-based certificates, which limit the 
risk of holding any particular private key. 
1.B.16 Comments on Risk 

Risk is essentially the chance that one will suffer a loss, 
and its maximum equals the amount of the potential loss. 
Risk management consists fundamentally and for the most 
part of (1) minimizing the probability and the potential loss, 
and (2) spreading the risk that cannot efficiently be elimi- 
nated. Despite best efforts to minimize risk, some possibility 
of loss usually remains. This residual risk is best borne by 
spreading it among a large number of similarly situated risk 
bearers, so that it becomes a moderate, known cost rather 
than the chance of a crippling catastrophe befalling a single 
enterprise. In the preferred embodiment, the technology and 
prescribed or recommended practices minimize risk, and 
assurance underwriters spread the risk among certification 
authorities and others by means of insurance, pooling 
arrangements, and other techniques for distributing residual 
risk in a broad-based manner. 

Multidimensional validity limits and two-stage certifica- 
tion enable the system to manipulate with precision the 
system's exposure to risk, while offering a high degree of 
assurance tailored to the needs of each relying party. 
Generally, an initial certificate and its replacements have 
little or no assurance, but higher-assurance secondary cer- 
tificates are available from a reliance server on request, 
based on the initial certificate. Defining the scope of assur- 
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ance in a customized secondary certificate lets the relying 
party proceed with a clear understanding of the precise 
extent of the assurance provided for a digital signature. It 
also lets the system manage the other side of assurance, the 

5 risk that a loss due to reliance will occur for which a 
participant in the system will be liable. 
2. SECOND EMBODIMENT 
2. A Overview of Second Embodiment 

An overview of the electronic transaction system 200 
according to a second embodiment of the present invention 
is described with reference to FIG. 6. A subscriber 202 is 
issued one or more certificates 204 from a certification 
authority within an hierarchy of certification authorities 206 
or from one of a number of sponsors 208. The certificates 
may serve to identify the subscriber 202 or to authorize 

35 certain transactions or types of transactions by the subscriber 
202. Copies of the certificates (or of relevant information 
from the certificates) is placed in repositories or directories 
210. Each certification authority and sponsor may have its 
own directory 210, or they may share directories 210. 

20 The subscriber 202 transacts with a party 212 (hereinafter 
the relying party) by forming and digitally signing a trans- 
action 214 which includes those of the subscriber's certifi- 
cates (or unique identifiers of the subscriber's certificates) 
required to identify the subscriber and to validate and 

25 authorize the transaction and then sending the transaction 
214 to the relying party 212. 

Upon receipt of the signed transaction 214, the relying 
party 212 verifies as much of the transaction 214 that it can 
or that it wishes to, and then composes a message 216 which 

30 it then sends to a reliance manager 218. The message 216 
can be one of various different kinds of messages, including 
either a signature guarantee request (SGR) message, a status 
check message (SCM), an over-limit guarantee (OLG) 
request and an unrely request message (URM) The OLG 

35 request will be made in the event of the rejection of a RCM. 
They permit the user optionally to request an increase in the 
subscriber's reliance limit. 

Preferably a purpose field is included in each message 216 
so that a reliance manager 218 knows which tasks to 

40 perform. An SGR informs a reliance manager 218 that the 
relying party 212 intends to rely on certain information 
included with the message (derived from the transaction 
214), and asks the reliance manager 218 to verify that the 
information is reliable and to guarantee the results of the 

45 check. For example, an SGR may specify that a relying party 
212 intends/wishes to rely on certain certificates for a $200 
transaction, and the reliance manager 218 is requested to 
check that the transaction will be good for that amount. 
A status check message is similar in form to an SGR, 

50 except that the relying party 212 does not actually request a 
guarantee, only an indication that such a guarantee would be 
given if requested. 

Over- limit guarantee requests are essentially the same as 
the reliance requests of the first preferred embodiment. 

55 However, a relying party 212 can make an OLG request 
without there being anything in the certificates to the effect 
that such a request is required. 

When the message 216 is an SGR or an SCM, it contains 
enough information for the reliance manager 218 to verify 

60 the subscriber information in the transaction 214. The rely- 
ing party 212 may also specify in the message 216 a 
category of transaction as well as those aspects of the 
subscriber's information in the transaction 214 (or, more 
precisely, in the certificates associated with transaction 214) 

65 on which it intends to rely. 

As noted, the relying party 212 can verify as much of the 
transaction 214 that it can or that it wishes to. Thus, for 
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example, a relying party 212 may verify all signatures, The liability trackers 220 store the current cumulative 

certificates and attribute values within the transaction and liability and the number of transactions for each certificate 

then just request that the reliance manager 218 check the for the period stated in the certificate. The certificates can be 

certificate serial numbers against CRLs. Alternatively, the indexed based on their unique identity (issuer name and 

relying party 212 may send the entire traasaction 214 to the 5 certificate serial number). 

reliance manager 218 for verification, doing nothing itself. Since a certificate may specify a class or category of 

The cost of the verification services performed by the reliance managers which can be used to validate that 

reliance manager 218 can depend on the amount of work it certificate, simultaneous attempts to read/write values for a 

is requested to perform. particular certificate at a liability tracker 220 are possible. 

When the reliance manager 218 gets a message 216 from TTiat is, it is possible that more than one reliance manager 

a relying party 212, it first determines what kind of message 218 is processing a copy of the same certificate and that 

it has received. If the message is an SGR or SCM, the more than one reliance manager is requesting reliance based 

reliance manager 218 tries to verify the information in the on that certificate. Accordingly, the liability trackers 220 use 

certificates provided by the subscriber 202 to the relying an appropriate locking mechanism to ensure consistent 

party 212 in the transaction 214. To verify this information, reading and updating of their records, 

the reliance manager may check with certification authori- 15 Each reliance manager 218, certification authority 206 

ties 206 and sponsors 208, or it may rely on information and sponsor 208 may, at any time, insure itself against some 

(e.g., CRLs or information from previous checks) that it has liability by obtaining insurance from an insurer 222. The 

previously obtained from those parties or from elsewhere, reliance manager 218 may be authorized to obtain insurance 

e.g., from directories 210. from insurers 222 on behalf of a certification authority 206 

The reliance manager 218 tracks the cumulative liability 20 or sponsor 208, depending on such factors as that authority 

of each certification authority 206 and sponsor 208, and or sponsor's current pending cumulative liability. The reli- 

periodically notifies them of this liability. The regularity of ance manager 218 may also obtain its own insurance from 

this notification may depend on the arrangement between the the insurers 222. 

reliance manager 218 and the parties, or it may depend on The reliance manager 218 bills the various parties for its 

the type or size of the transaction or liability. For example, 25 services via billing service 224. The reliance manager 218 

in some cases a certification authority may wish to be also bills the appropriate party for the use of the certificates 

notified immediately of certain transactions or types of being relied upon by the relying party 212. This may take the 

transactions, such as transactions exceeding a certain form of requiring an immediate electronic payment, e.g., 

amount of money, transactions by particular entities, trans- from an unknown relying party, debiting a pre-established 

actions which would cause its cumulative liability to exceed 30 deposit account, e.g., of a sponsor, or sending a periodic 

some value, transactions at certain times of day or any invoice to a sponsor or relying party with established credit 

combination these and other conditions. In this way, a and payment history. 

certification authority 206 or a sponsor 208 would be able to Having processed a message 216 (e.g., verified an SGR or 

act immediately, if necessary, to insure for liability against SCM, or processed an OLG request), notified the appropri- 

those transactions. 35 ate parties, obtained the appropriate insurance and billed for 

There may be more than one reliance manager 218, and the services provided, the reliance manager 218 then sends 

different transactions 212 or different parts of the same a reliance manager receipt (RMR) 226 to the relying party 

transaction 214 may have to be verified by different reliance 212. This RMR 226 informs the relying party 212 of the 

managers. In order for the various reliance managers 216 to outcome of the status checks and of the amounts charged for 

track the cumulative liability associated with each outstand- 40 those checks, or, in the case of an over-limit guarantee 

ing certificate, global liability tracking servers 220 are used. request, of the response to that request which may be either 

Each liability tracking server 220 acts as a global shared a guarantee receipt or a reject message. The RMR receipt 

memory for the electronic transaction system 200, allowing 226 can be digitally signed by the reliance manager 218, 

cumulative liabilities associated with each outstanding cer- with the date and time and a digest of the message, thereby 

tificate to be read and written by reliance managers 218. 45 acting as proof of the verification performed by the reliance 

Only one liability tracking server 220 may be used for each manager. The reliance manager 218 can, if needed, archive 

certificate. The liability tracking servers 220 can be separate the message 216, the signed receipt 226 and any other 

entities or they can be a part of the directories 210, the CAs information related to the processing of that message 216. 

206, or the sponsors 208. If a particular certificate can only The transaction 214, the message 216 and the RMR 226 

be processed by one reliance manager, then that reliance 50 can be digitally signed by an independent timestamp server 

manager can track the cumulative liability associated with 228 when created. 

that certificate. These liability tracking servers provide a Upon receipt of the RMR 226, the relying party 212 can 

general "inhibit" function to detect and prevent over- store the RMR and, depending on the information in the 

reliance on a certificate. The "inhibit" service is generally RMR 226, continue the transaction with the subscriber 202. 

performed by a high availability system under contract to the 55 While shown in FIG. 6 as separate entities, the billing 

issuing CA. service 224 and the reliance manager 218 can be part of the 

Certificates can specify a reliance limit or a reliance limit same entity, in which case the various parties to a transaction 

per period of time, e.g., per hour, day, week, month, year, 24 (e.g., certification authorities, sponsors, subscribers and 

hour period, weekday, etc. Thus, one certificate may have a vendors) can have accounts with the reliance manager 218. 

reliance limit of $200 per day, while another has a reliance 60 The reliance manager will keep separate totals for status 

limit of $500. Similarly, certificates can specify a number of check fees owed to itself and reliance fees owed to CAs, 

transactioas per time period, e.g., per hour, day, week, sponsors and insurers, and will periodically perform a sepa- 

month, year, 24 hour period, weekday etc. Thus a certificate ration and settlement of all these charges, collecting any 

may specify ten transactions per day. Combinations of these funds due and remitting all funds collected to the appropriate 

may apply, e.g., five transactions per day, not to exceed $500 65 parties, less any service fees. 

per day. Beyond this, an OLG request would be required to On a periodic basis, upon request of the subscriber, the 

be granted at the discretion of the reliance manger 218. reliance manager, or the global liability tracking ("inhibit") 
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service, if one is being used, will send to the subscriber a Thus, the status service will detect that a specific digital 

statement listing all signatures of that subscriber that have signature has been checked and insured before, and will 

been presented to the reliance manager, including the iden- reject any attempt to re-check it at the sponsor's expense, 

tity of the relying party, the reliance limit requested (if any) which could incur unreasonable charges, 

and the fees charged. This statement may be delivered via 5 In some cases, and when authorized, the certificate 204 

conventional paper-based mail, electronic mail, or may be will also include the name and account number of a third 

browsable via a Web server by the subscriber at any time. party who has agreed to cover the status check and guarantee 

The statement's purpose is to remind the subscriber of the fees. 

signatures it has issued, and to allow it to possibly identify Alternatively, the certificate 204 may not be an identity 

any signatures that may have been falsely issued or improp- 10 certificate which links a subscriber name to a public key, but 

erly relied on. rather one which confers some privilege or authority on the 

Further, while shown in FIG. 6 as separate entities, the subscriber (i.e., an authorization certificate as described in 

subscriber 202 may, in some circumstances, itself be the U.S. application Ser. No. 08/277,438 to Sudia, filed Jul. 19, 

relying party 212. For example, a subscriber 202 may wish 1994, titled "Method for Securely Using Digital Signatures 

to determine whether a particular transaction would be 15 in a Commercial Cryptographic System/' the contents of 

acceptable for a signature guarantee before sending that which are hereby fully incorporated herein by reference), in 

transaction to another party. conjunction with an identity certificate. Such an authoriza- 

2.B Detailed Description of Second Embodiment lion certificate may also have an associated system of 

The process of a certification authority CA-n issuing a transaction limits which requires administration by a reli- 

certificate 204 to a subscriber 202 is now described with 20 ance manager, and accordingly will have added to it the 

reference to FIG. 6. The subscriber's certificate 204 is stored same or a similar set of "reliance specification" fields 

in some preferably secure location, e.g., in the subscriber's described above. 

trusted secure device 230 (see FIG. 7) which can be a smart When the certification authority CA-n (or a sponsor) 

card or the like. issues a certificate 204, a copy of relevant information from 

The subscriber's certificate 204 has an X.509 form (as 25 that certificate is sent to an appropriate repository or direc- 

shown in FIG. 12) and includes the following information or tory 210. The information sent to the directory 210 includes 

attributes: the certification authority name, the serial number of the 

1. The name of the issuer of the certificate. certificate and, in the case of an identification certificate, the 

_ A . .-a . * i u / * .u * *u public key of the subscriber. The certificate information is 

2. A unique certificate serial number (note that the com- *\ * . .. . , nxjr . n „ ... 
,. ^ c tl _ *-r *• <t_ v a *l 30 also sent to a status checking service (KM). Generally this 
bination of the certification authority name and the nikM .„ . . . f .„ ,\ ' ; 

., . RM will be the same as that specified in the certificate, 

certificate serial number uniquely identifies a _ , * t , .. 

. fi v In an hierarchical certification system, each certification 

cer l ca e;. authority will itself be certified by another CA, with one of 

3. The subscriber's public key. lfac CAs being certificd by tne rool certification authority 

4. The reliance limit set by the issuer, e.g., a maximum 35 CA-0. Each certification authority publishes appropriate 
dollar amount transaction and/or per time period (day, information about the certificates it issues in some directory 
week, month, year, etc.). 210. The certification authorities can use the same or dif- 

5. Whether the status of the certificate must be checked ferent directories 210. 

before the issuer will assume any liability for reliance A CA's certificate (from its parent) contains similar 

on information in the certificate. 40 attributes to those listed above for the subscriber certificate 

6. The name and optionally a network address of at least 204. The CA's certificate also contains an attribute speci- 
one status checking service (reliance manager 218) fying whether the parental limits apply only to the subscriber 
approved by the issuer at which this certificate can be or whether they apply to the aggregate daily volume of all 
checked as well as a suitable address for its directory subscribers of a named certification authority. 

210. If an X.500 directory lookup system is used, then « With reference to FIG. 7, a trusted device 230 according 

the name and address will be the same, otherwise, it 10 preferred embodiments of the present invention includes 

may be necessary to specify a valid network address a tamper resistant numerical counter 232. This counter 

and means of communication. increases monotonically by some value, e.g., one, each time 

_ ™ u , . . , . . u , . r the device is used to create a digital signature. Further, the 

7. The checking service s status checking fee. . 6 u * . * 

n ^ „ , * x 50 current value of the counter is embedded as a signature 

8. The guarantee fee (per dollar amount of reliance). y ^ ^ ^ bk)ck signed by ^ devke 

9. Who will pay the status check fees (subscriber, certi- 230. 

fication authority or sponsor). By sequentially numbering each signature of a device (or 

10. Whether the subject/subscriber of this certificate is a 0 f a user), and then collecting each of these numbers when 
device. 55 the signatures are submitted to a reliance manager, possible 

11. Whether signer/device numbers its signatures, and, if tampering and counterfeiting of devices or theft and unau- 
so, whether the numbering is (a) sequential or (b) thorized use of private signature keys can be detected. If a 
pseudo-random. private signature key is extracted from a device, it may be 

The certificate 204 may also include an optional field used to sign transactions that look, when accompanied by 

granting permission for the status check service to bill some 60 the manufacturer's device certificate, as if generated in a 

or all of its fees to either the sender/signer or another third trusted manner by that device. However, when used outside 

party (typically the signer's employer or sponsor) instead of the device, they may be used to create improperly formed 

requiring the relying party to pay them. When this feature is transactions. 

used, the status service keeps a record of the signature The signature numbering method described herein cannot 

number or of the signature value (or some value derived 65 detect mere use outside a device, but it can help to detect 

therefrom) to prevent the same or different relying party counterfeiting or reproduction of false devices using a 

from utilizing the third party billing feature more than once. legitimate device signature key and certificate obtained by 
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removing a tamper resistant coating, or the like. We assume 
that the goal of counterfeiting is to produce and sell a 
significant number of devices based on tampering with a few 
legitimate devices — since the cost of successful tampering 
will be fairly high. Thus, by requiring a sequential number 5 
with each signature, we allow for the possibility detection by 
a centralized system that collects and compares these num- 
bers. If duplicates occur, or if numbers are received far out 
of sequence (due to thieves setting each counter to a different 
base value) then the system can detect, investigate and 10 
possibly revoke the affected device certificate. 

This scheme is strengthened if the trusted device also 
contains a reliable time clock that can place a time value into 
each signature along with the counter value. This can allow 
the reliance manager to sort the incoming transacting sig- 15 
natures by their creation dates, thus making it much easier 
to spot signature numbers that are out of sequence. 

As a further variation, we can generate the signature 
numbers (a) by using a pseu do -random number generator 
(PRNG) with a seed known to the CA and the reliance 20 
manager so they may compute the expected sequence of 
numbers, or (b) by starting with a base value and then adding 
an increment that are both a function of the specific device 
manufacturer. 

For example, both the initial starting value of the counter 25 
232 and its increment per transaction can be randomly set by 
the device manufacturer 234 when the device is certified, 
and then these values can be incorporated, along with other 
information, into the device certificate 236 in the device 230. 

Each device manufacturer 234 may be assigned a different 30 
counting factor, preferably a prime number greater than one, 
and the increment for the counter 232 can be set, at the time 
of manufacture, to be a random value multiplied by this 
factor. Thus, for example, if there are three manufacturers of 
secure cryptographic devices 230, namely Ml, M2 and M3, 35 
then Ml would be assigned the factor 3, M2 the factor 5, and 
M3 the factor 7. Then, for each device that manufacturer Ml 
manufactures, it generates a random number, R, and sets the 
increment for the counter 232 to be "3xR". Similarly, 
manufacturer M2 would set the increments of counters in its 40 
devices to be 5 times a random number, and manufacturer 
M3 would set its increments to be 7 times a random number. 
The range of the random numbers used to determine the 
increments can be limited, for example, from 1 to 200, and 
can also exclude prime numbers. The initial starting value 45 
may also be determined using this factor. 

Instead of storing the increment itself, the device certifi- 
cate 236 issued by the manufacturer need only store the 
random value R used to determine the increment or the seed 
of the random number generator used to determine R (as 50 
long as the random number generation algorithm is known). 

The device 230 contains a copy of the subscriber's private 
key 238 (corresponding to the public key stored in the 
subscriber's certificate 204 and in the directory 210). 

The device manufacturer 234 is itself certified by a 55 
certification authority CA-m in the certification authority 
hierarchy under the root certification authority, CA-0. Thus, 
the device certificate 236 in trusted device 230 can be 
verified using the manufacturer's public key (stored in the 
directory 210-m for certification authority CA-m). 60 

With reference to FIGS. 1-8, when a subscriber 202 
creates a transaction 214, the subscriber generates a message 
240 containing the transaction details 242, a copy 244 of the 
subscriber's certificate 204 (issued by the certification 
authority CA-n) and copies 246 of other relevant certificates. 65 
Instead of copies of the actual certificates, the subscriber 202 
may include unique identifiers e.g., (issuer name and cer- 
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tificate serial number) for some or all certificates. The 
subscriber 202 then digitally signs a combination of the 
transaction 242 with various signature attributes 248 using 
his private key 238 to produce a digital signature 250. 

If the subscriber's trusted device contains a signature 
counter 232 and time clock 239 as described above, then the 
other certificates 244 may include information such as 
copies of the device certificate 236 (so that the starting value 
and increment of the counter can be determined) and the 
signature attributes 248 must include the current value of the 
counter 232. If the device increments by one each time, no 
device certificate is needed. The copy of the device 
certificate, if needed, is used later to check for anomalous 
values of the counter 232 stored in the signature attributes 
248. Typically the device certificate will have been submit- 
ted to the CAat the time the user's key was certified, and so 
its contents will already be known to the CA and to any RM 
or global inhibit service that it contracts with. 

Anomalous values of the counter include values that are 
far out of sequence, values that have been previously seen on 
different transactions values that do not correspond to those 
which could be issued by that manufacturer, and values 
which do not correspond to those which could be issued by 
that device used on the information in the device certificate 
236). If transactions are time stamped (e.g., contains a time 
value from an internal time clock 239), then even if trans- 
actions are submitted out of sequence, it is possible to 
determine whether or not a counter value is legitimately out 
of sequence. 

Preferably the subscriber's private key 238 is stored in the 
subscriber's trusted device 230, as is the subscriber's cer- 
tificate 204, however, either or both of these can be stored on 
a secure computer or some other secure storage device. 

The digital signature 250 can be produced in any accepted 
and known manner. For example, the signature can be 
formed using RSA or DSA. The digital signature 250 and 
signature attributes 248 can include a PKCS-7 signature 
block which contains hashes of the attached certificates 244 
and 246, an indication as to whether or not the signer is a 
device, a signature number unique to this private key (the 
counter 232 value) and preferably an associated time-stamp 
(from internal time clock 239) indicating when the signature 
was made. In the case of a secure device 230 with a counter 
232, the signature number is the current value of that 
counter. 

2.B.1 Relying Party Receives Transaction 

When a relying party 212 receives a transaction 214 
formed as described above, it can do a number of things, 
depending on how much information is contained in the 
transaction 214 and on how much it wants the reliance 
manager 218 to do. 

With reference to FIG. 9, the relying party 212 receives 
the transaction 214 (step S200) and performs some or all of 
the following steps: 

If the relying party 212 wants the entire transaction 214 
checked by a reliance manager 218, it proceeds by deter- 
mining the address(es) of the appropriate reliance manager 
(s) 218 to which the entire transaction 214 will be sent (step 
S210). 

Otherwise, the relying party 212 extracts the copy of the 
subscriber's certificate 242 and the other certificates 244 (if 
any) from the traasaction 214 (step S202). Recall that some 
or all of these certificates 242, 244 may not be present. They 
may have been sent previously, be obtainable from 
directories, or be left for the reliance manager to obtain. The 
transaction 214 should contain at least a unique identifying 
reference (e.g., issuer name and serial number) to the 
subscriber's certificate 204. 
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At this point the relying party 212 can either further 
validate the transaction 214 itself, or it can go directly to the 
address determination step (S210), letting the reliance man- 
ager 218 check the entire transaction 214. 

If the relying party 212 decides to further verify the 
transaction 214, it then retrieves any missing certificates 
(step S204). The missing certificates are obtained from the 
appropriate directory 210 or the relying party 212 may have 
retained copies of them from prior retrievals. This certificate 
retrieval process is done by working upward from each 
provided certificate to find all parent certificates, working 
toward a known good root key. 

Thus, for example, if the transaction 214 was signed by 
the subscribed of FIG. 2, and the transaction contained only 
subscriber's certificate, then the relying party 212 would 
have to obtain the certificate issuer's certificate (i.e., CA-5's 
certificate), and then CA-l's certificate. On the other hand, 
if the transaction was signed by subscriberl of FIG. 2, and 
the transaction contained certificates for subscriberl, CA-1, 
CA-2, CA-3 and CA-4, then the relying party 212 would not 
have to obtain any more certificates in order to verify 
subscriber's signature. 

Again, at this point, the relying party 212 can continue to 
verify the transaction 214 itself, or it can go directly to the 
address determination step (S210), giving the reliance man- 
ager 218 more of the transaction 214 to check. 

Having obtained all the required certificates (in steps 
S202, S204), the recipient verifies the certificate chain (step 
S206), working downward from the root to the signer, 
verifying policy controls in the certificates on the way down. 
The relying party 212 then re-hashes the message and 
checks the signature against the base signer's certificate 
(step S208). 

2.B.2 Relying Party Determines Address(es) of Status 
Service(s) 

Before having any aspect of a transaction 214 verified by 
one or more reliance managers 218, the relying party 212 
must determine which reliance manager(s) to use. Each 
subscriber certificate includes either the name of a status 
checking service (reliance manager 218) at which that 
certificate can be checked as well as a suitable address for its 
directory 210, or the relying party 212 must obtain that 
information from the appropriate certifying authority 206. 
Thus, given a certificate, it is possible to determine which 
reliance manager to use to verify aspects of that certificate. 

Accordingly, in step S210, if the relying party 212 has not 
already obtained at least one appropriate certificate (in step 
S202), it does so and determines from that certificate the 
name of a reliance manager 218 (or a class of reliance 
managers) at which that certificate can be checked. 

On the other hand, if the relying party had already 
obtained at least one certificate (in step S202), it uses that 
certificate to determine the name of a reliance manager 218 
(or a class of reliance managers) at which that certificate can 
be checked. 

If the relying party obtained all certificates associated 
with the transaction, it determines the appropriate reliance 
manager 218 for each certificate. 
2.B.3 Relying Party Creates A Message 

Having received a transaction 214 (step S200), and veri- 
fied as much of that transaction as it desires (steps 
S202-S208), the relying party 212 next creates one or more 
messages (either SGR, an SCM or an OLG request) 216 
(step S212) to be sent to one or more reliance managers 218. 

However, before creating any messages 216 (step S212), 
the relying party 212 must determine which reliance 
manager(s) 218 to send the message(s) 216 to. Since there 
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might be more than one message 216 if multiple reliance 
managers are involved, the relying party 212 must first 
determine how many reliance managers are involved. 
When a certification authority 206 or sponsor 208 issues 

5 a certificate, it specifies, in the certificate, a status checking 
service (reliance manager 218) at which this certificate can 
be checked. The status checking service can be specified by 
name, class of provider or in some other manner. Thus, a 
certificate issuer may determine that only a particular reli- 

10 ance manager 218 can verify its certificates (and so specify 
in its certificates), or it may allow its certificates to be 
verified by any reliance manager 218 that meets certain 
requirements (as specified by a reliance manager class). 
The relying party 212 next analyzes the certificates requir- 

15 ing status checking in order to determine the address(es) of 
status services (reliance managers) 218) to use for transac- 
tion verification (step S210). 

The contents of the message(s) depend on what it is the 
relying party 212 wants the reliance manager(s) 218 to do. 

20 First, the relying party 212 may provide the reliance 
managers(s) 218 with the entire transaction 214 or with only 
parts of the transaction. Second, the relying party 212 may 
provide the reliance manager(s) 218 with all certificates 
associated with the transaction or it may provide only unique 

25 identifiers for only some of the certificates. Third, the relying 
party 212 may ask the reliance manager(s) 218 to validate 
the entire transaction or only some aspects thereof. 

The various functions that the relying party 212 can 
request of the reliance manager(s) 218 include: 

30 (1) Given only the unique identifiers of certificates, check 
whether or not those certificates have been revoked 
(i.e., are listed on CRLs) or suspended. 

(2) Given a set of actual certificates, check whether or not 
they have been revoked or suspended. 

(3) Given a combination of certificates and unique cer- 
tificate identifiers, check whether or not those certifi- 
cates have been revoked or suspended. 

(4) Verify certificate chain to see if certificates actually 
40 verify each other. Note that the RM can store most 

certificates in a pre-verified state to avoid the need to 
perform digital signature computations repeatedly. 

(5) Same as above in (l)-(4), but check entire transaction, 
including the digital signature of the original subscriber 

45 who signed it. 

As noted above, the message 216 can be one of various 
different kinds of messages, including either an SGR (which 
informs a reliance manager 218 that the relying party 212 
intends to rely on certain information included with the 

so message and asks the reliance manager 218 to verify that the 
information is reliable); an SCM (which is similar in form to 
an SGR, except that the relying party 212 does not actually 
request a guarantee, only an indication that such a guarantee 
would be given if requested) or an OLG request. 

55 If the message 216 is an SGR or an SCM, it includes a 
monetary to value (for reliance purposes) which the relying 
party 212 initially determines from the transaction 214. If no 
monetary value is provided in the transaction 214 or if the 
relying party wants to rely on a different value than that 

60 provided (for example, if the relying party 212 self insures 
for some amount), the relying party can set the monetary 
value in the message 216 accordingly. However, to prevent 
the relying party 212 from stating a monetary value in excess 
of the value stated in the transaction 214, thereby perhaps 

65 prematurely exhausting the subscriber's maximum allowed 
limits, the transaction's signature attributes 248 should 
include the actual stated value of the transaction, and the 
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message 216 should include this actual stated value by 
including the signature attributes 248. 

If only a status check is desired, either a status check bit 
can be set in the message or the monetary value in the 
message 216 is set to zero. Preferably a status check bit is 
used to avoid overloading of data values with semantics. In 
this case the message 216 (an SCM) will be used to request 
confirmation of the status of the various certificates, but will 
not be used to purchase any guarantees. 

A message 216 (SGR or SCM) contains the following (not 
necessarily in the given order): 

1. The name and network address of the relying party 212. 

2. A unique sequence number so duplicate messages 
(RCMs in particular) can be rejected. 

3. Account information with the billing service 224 for 
billing purposes (even if the signer or sponsors pay). 

4. An optional intent to request extension if over the 
allowed/remaining reliance limit. 

5. A list of certificates or certificate unique identifiers 
(e.g., issuer names and serial numbers). 

6. A signature sequence number and timestamp (if present 
in the transaction 214). 

7. A hash of the message (transaction 214) being checked. 
Optionally the entire message can be appended for 
checking and/or archiving. 

8. A date and time of request can be (provided by 
timestamp server 228). 

9. An optional list of categories for this transaction. 

10. A request to archive even if status check fails; or to 
archive even if over reliance limit. 

11 . An archive retrieval password, encrypted with reliance 
manager service's public key. 

12. A purpose for this message (guarantee request, status 
check billing approval, etc.). 

13. A role (relying party) 

14. A hash of the relying party's billing service certificate. 

15. The relying party's signature for charging the account 
at the billing service 222. 

2.B.4 Relying Party Sends Message(s) 

Having determined the addresses) (step S210) and cre- 
ated the appropriate message(s) (step S212), the relying 
party 212 then determines the total of base checking fees 
requested and the total of reliance guarantee fees requested 
per dollar amount of reliance value (step S214). 

With the messages 216 created, they are sent (step S216) 
to the appropriate reliance manager(s) 216. The messages 
216 are sent using whatever transport mechanism is speci- 
fied in directory entry for the reliance manager, e.g., sockets, 
HTTP, e-mail, and the like. 
2.B.5 Processing by Reliance Manager 

1. Receive Message 

Upon receipt of a message 216 from a relying party 212 
(step S218), the reliance manager 218 performs the follow- 
ing operations (with reference to FIG. 10). 

2. Verify Message Syntax 

First the reliance manager 218 verifies (step S220) mat the 
general syntax of the message 216 is correct. If the syntax 
is incorrect, the reliance manager 218 notifies the relying 
party 212 and ceases processing. A relying party 212 may be 
billed for a syntactically incorrect message. 

If the syntax of the message 216 is correct, then, if the 
relying party 212 has an account with the reliance manager 
218 (i.e., if the reliance manager and the billing service 224) 
are the same entity, the reliance manager looks up the 
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relying party 212 public key which it has stored locally, 
hashes the message 216 and verifies the relying party's 
signature. 

If the relying party 212 does not have a pre-established 
5 account with the reliance manager 218, the reliance manager 
must verify the relying party's signature on the message 216 
by some conventional approach, typically verifying the 
chain of certificates which specify the relying party's public 
key. 

3. Determine Minimum Fees 

Next, the reliance manager 218 determines the minimum 
amount due on this verification transaction and verifies 
available funds in the relying party's account (step S222). 
Sometimes the reliance manager 218 cannot determine the 
full amount due on a transaction until the entire transaction 

15 has been verified. If the reliance manager 218 and the billing 
service 222 are separate entities, then the reliance manager 
can either bill the relying party's account with the billing 
service or contact the billing service to determine whether 
the relying party is in good standing with them and has funds 

20 or credit available. 

4. Determine What is being Requested 

Subsequent activities of the reliance manager 218 depend 
on what the relying party 212 requested in the message 216. 
The reliance manager 218 determines what it is that is being 
25 requested (step S224) and validates the message accordingly 
(step S226). 

5. Validate Message 

In one possible case, the reliance manager 218 is given (in 
the message 216) the unique identifiers of various certifi- 

30 cates and/or actual certificates, along with a requested reli- 
ance limit. The reliance manager 216 checks whether or not 
those certificates have been revoked (i.e., whether or not 
they are listed on CRLs) or suspended. 
The reliance manager 218 must first check to determine 

35 whether the requested reliance is less than or equal to the 
value of the transaction 214. The signature attributes block 
248 of the transaction includes the value of the transaction, 
and this block, along with the actual signature, are provided 
to the reliance manager along with the relying party's 

40 requested liability. If the requested reliance exceeds the 
value of the transaction, the reliance manager should reject 
the request. In such cases, the reliance manager should 
notify the subscriber 202 and other parties of the request. 
The reliance manager can thus verify the signature and 

45 from the block can extract the subscriber's declared trans- 
action value prior to utilizing the subscriber's available 
reliance limit. If the entire transaction has been submitted, 
the RM can also hash it to see if it matches the transaction 
hash contained in the signature attributes block. These 

so processes of checking the signature block or the entire 
message can generally be omitted for smaller value message, 
where it is appropriate to rely on the declared values 
provided by the relying party. In such cases, the signature 
guarantee or other transaction insurance provided by the 

55 reliance manager will simply be void if there is any mis- 
statement by the relying party, so it is not in his interest to 
submit incorrect values. 

For each certificate listed in the message (either by serial 
number or by being provided), the reliance manager 218 

60 checks that certificate's serial number against the appropri- 
ate CRL, i.e., the CRL from the issuer of that certificate. If 
the certificate has been revoked or suspended, the reliance 
manager notes the invalidity of that certificate and continues 
with any remaining certificates. If any certificate is invalid 

65 the entire transaction is considered invalid. 

For each certificate checked, the reliance manager 218 can 
notify the issuer of its use and of the reliance value being 
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associated with that certificate (step S228). Such notification 8. Archive Message if Requested 

can be monthly, daily, weekly, hourly, or per transaction If the message 216 requests an archive and the full 

above a pre-approved amount. document is attached then the document is rehashed and the 

6. Update Global Reliance Limits signature as submitted is verified. If the result of this is not 
The reliance manager 218 can also read the current 5 the same as the transaction submitted then the archive 

cumulative liability for that certificate from the appropriate requcst ^ re j C cted, otherwise the message is archived (step 

global liability tracker 220 assuming more than one RM can §234 ) 

validate If the current cumulative liability exceeds the ^ re , ; , 212 js then bi]led for ^ injtia , archiv6 

requested liability, the transaction is invalid and is rejected iod requested the default period being six months . ^ 

The reliance manager notifies the relying party if it will m ^ notified ^ he ^ ^ biUed for 

consider processing an over-limit guarantee request. , ■ • , tl • * j j L ^ 

Otherwise, if the current cumulative liability in addition to ™sive archive periods. Hie receipt provided by he 

the requested liability does not exceed the limit on that rehance mana S er contains . a transcript, a hash of the 

certificate, the cumulative liability should be updated to transaction and is signed using a long archival signature 

reflect the requested amount (step S230). ke V ( of at least 1800 blts ) 50 the ™* r can archive the 

Because of potential synchronous update attempts of the 15 transaction anywhere. It is, however, convenient to let the 

cumulative liability, the reliance manager may need to RM validate store the transaction as a "one-step shopping" 

obtain a lock on the values for all certificates used by the arrangement, 

transaction with the corresponding liability trackers before 9. Verify Signing Device 

doing any reading or updating of values. Alternatively, it can If the signer of the transaction 214 was a device (or 

use an optimistic commit strategy, write new values as each 20 device -confined subscriber private key), then the reliance 

certificate is processed, and roll back any change in the event manager 218 checks for anomalies based on the history of 

of a later failure (over limit). The updating of these records signatures produced by this device (verify device, step 

can be performed in any manner known in the art. Further, S236). The reliance manager saves the transaction record 

in some cases, only a few of the certificates have their with the issuer name, certificate number, signature sequence 

associated liability checked. The last one (of the subscriber 25 num ber, and the date and time of receipt of the message 216. 

202) is the most important one to monitor closely. some per i 0 d, the reliance manager 218 sorts these 

In some cases the reliance manager 218 will be asked to transactions and checks for anomalies in sequence number 

check an entire transaction. In these cases the reliance afld date . time vahies of ast transactions. If the device has 

manager will obtain all the certificates associated with the mamifacturer s ecific startin values and increme nts, the 

ransaction, check them for validity and cons^tency and 3Q afe rf ^ whelher {h 

then process them as above with respect to the liability limits e ^ . t J 

requested follow the correct sequence. 

Once the reliance manager 218 has determined the status f f a ° out of value is found, (such as a counter 

of a particular certificate, the reliance manager 218 can value lhat 15 re P eated for dlffereDt transactions, out of order 

create a record for that certificate. This record can be created Wlth respect to the associated timestamp, or with a large 

regardless of the certificate's status. The record lists all ^ unexplained gap since the preceding value) the certificates 

certificates on which this certificate depends and all certifi- for that device and that subscriber should be revoked imme- 

cate which depend on this certificate. In this way, chains of diately. Therefore, the issuing certification authorities are 

certificates can be verified in a single table lookup. When- notified so that they can add the user and device certificates 

ever a CRL is received or whenever the reliance manager to the appropriate CRL. The reliance manager 218 may also 

determines that a particular certificate has become invalid 40 notify device owner/subscriber, if known, as well as the 

(revoked or suspended) it can update its records, invalidat- issuing certification authority or sponsor, the device 

ing chains as appropriate. manufacturer, and possibly law enforcement authorities. 

The reliance manager also records all parties who have The liability tracking servers 220 can be used by the 

relied on each certificate. Whenever a CRL is processed or reliance managers 218 to read and write current values of 

whenever the reliance manager determines that a particular 45 device signature numbers. Each device certificate 236 or 

certificate is invalid, the reliance manager can inform all each subscriber certificate 204 can have a corresponding 

parties who have relied on that certificate within a certain entry at a liability tracker 220. A reliance manager can 

period of time, such as 1-2 weeks. This is sometimes update the global signature number entry each time it 

referred to a "lookback notification/' and it can help parties processes a signature. In this way duplicate or fraudulent 

who recently relied on a certificate prior to its revocation 50 signatures are more quickly detected, 

determine if there may be any problems with prior 10. Obtain Insurance 

transactions, e.g., possible fraudulent transactions issued by In some instances the reliance manager 218 may obtain 

a thief prior to discovery of the theft of the signer's key, and insurance (step S238), either to cover its own assumed risks 

reporting to the CA for certificate revocation. in validating a transaction or on behalf of a certification 

If all certificates associated with a message are acceptable, 55 authority or sponsor. Topically, the reliance manager will be 

then the reliance limit for the appropriate period on each an authorized agent of one or more insurance companies that 

certificate is incremented according to the reliance requested is authorized to write small signature guarantee policies on 

in the SGR. their behalf, subject to pre-established terms and conditions 

7. Determine Fees and Bill Parties and premium rates. The RMR (receipt) will list the reliance 
The reliance manager 218 then writes the transaction for 60 amount, the fee paid, and may optionally list the name of the 

later batch processing, during which it increments guarantee insurance company underwriting the signature guarantee, 

fees collected on each certificate and accumulates guarantee 11. The Reliance Manager's Response to the Relying Party 

fees by issuing certification authority name (step S232). Having verified the message 216 (to the extent requested 

If any certificate is not acceptable then the relying party by the relying party 212), and having billed and notified the 

212 (or the subscriber 202) is billed only for the base 65 appropriate parties, issued or purchased the appropriate 

checking fee, and the reliance and guarantee fees do not insurance and stored the required records, the reliance 

apply. manager 218 then creates and sends a reliance manager 
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response (RMR) 226 which it digitally signs and sends back 
to the relying party 212 via same method as the message 216 
was sent, e.g., sockets, HTTP, e-mail, etc. (step S240). The 
receipt 226 can be timestamped by timestamp server 228 
prior to being sent to the relying party 212. It is preferred 
that the timestamp server be a different physical and legal 
entity, so that if one or the other (reliance manager or 
timestamp service) is compromised, it will at least be 
impossible to backdate seemingly valid transactions. 
The receipt 226 includes the following information: 

1. The identity of the reliance manager 218. 

2. A unique identifier (sequence number) for this receipt. 

3. The identity of the relying party 212 (and optionally its 
address). 

4. The relying party's unique message sequence number. 

5. A hash of the message checked. 

6. The date and time processed (declared value). 

7. The results of the request, including: 

whether the certificate status checks were acceptable 
whether the amount was within requested reliance 
limits, and 

whether the message was archived, and, if so, an 
archive retrieval identification number 

8. If any status checks failed, a list of status/reason codes 
by certificate. 

9. The relying party's requested reliance limit (might be 
zero). 

10. If the signer (subscriber 202) is over her limits, 
whether the service (reliance manager 218) supports 
over-limit exception processing. 

11. If over-limit process was requested by relying party, 
what method is used for this. 

12. If the status checks and reliance limit were acceptable, 
a list of fees paid by certificate checked and total fees 
billed to subscriber and/or third parties, and the total 
fees billed to relying party's account. 

13. Whether the message had been previously checked 
and whether the subscriber/sponsors were out of funds. 

14. A signature of the status check service 218. 

15. A signature and time of timestamp server 228. 
2.B.6 Status Check Fee Considerations 

There may be a base fee per certificate check requested, 
even if the check falls. In some cases, there may be a higher 
fee if the certificate is acceptable, even with zero reliance. 
2.B.7 Over-Limit Guarantee (OLG) Request 

If a relying party 212 requests an over-limit guarantee, 
that party sends (as message 216) an over-limit guarantee 
(OLG) request to the reliance manager 218. The OLG 
request is used to request a guarantee over the reliance limit 
stated in the certificates associated with the transaction 214. 

The OLG request includes the requester's name and 
network address, a unique identifier (sequence number) for 
this OLG request, a billing service account number for 
billing purposes, a list of certificate issuer names and serial 
numbers, for this status checking service: 

1) signature sequence number (if present); 

2) hash of the message being checked; 

3) quoted cost of over-limit guarantee fee; 

4) date and time of request; and 

5) verifier's signature for charging the deposit or billing 
account. 

The reliance manager 218 responds to an OLG request 
message with a similar response to the RMR response, 
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except that the reliance manager 218 approves and guaran- 
tees the relying party's requested over-limit reliance 
amount. 

2.B.8 Final Processing by Relying Party 

s When the relying party 212 gets a receipt 226 from a 
reliance manager 218, it first checks that the receipt 226 has 
been sent to the correct relying party 212 by looking at the 
identity of the relying party as stated in the receipt 226. Next 
the relying party 212 associates the receipt 226 with a 

10 message 216 which it sent out. To make this association, the 
relying party 212 checks the value of the unique message 
identifier (sequence number) in the receipt 226. If the relying 
party 212 does not find a message 216 corresponding to this 
receipt 226, or if the receipt has been sent to the wrong 

15 relying party, the recipient can either notify the reliance 
manager of the inconsistency found or simply ignore the 
receipt and do nothing. 

Having determined that it is the correct recipient of the 
receipt 226 and having found the message 216 correspond - 

20 ing to the receipt, the relying party 212 verifies the signature 
of the reliance manager and evaluates the receipt to deter- 
mine the outcome of the reliance manager's processing. In 
other words, the relying party 212 examines the receipt 226 
to determine whether the message 216 passed the requested 

25 certificate status checks; whether the amount was within 
requested reliance limits; and whether the message was 
archived. If the message was archived, the relying party 
stores the archive retrieval identification number. 

The relying party 212 then detaches and stores the receipt 

30 226 which serves as an advice. Note that the receipt is good 
only with respect to this specific relying party and may not 
be relied upon by another party without payment of an 
additional signature guarantee fee. Where a prior receipt is 
submitted, the reliance manager may offer a discount to 

35 subsequent relying parties for the same document or trans- 
action. 

Next, if the receipt 226 indicates that the status checks and 
reliance limit were acceptable, the relying party 212 
evaluates, records, and deducts the fees billed to its account 

40 with the billing service 224. 

If the status checks fail because the subscriber 202 is over 
its limits, the relying party determines from the receipt 226 
whether the reliance manager 218 supports over-limit excep- 
tion processing, and then decides whether to request such 

45 processing. 

Recall that a particular transaction 214 may require that 
messages be sent to more than one reliance manager 218. 
The relying party 212 must wait for all reliance managers to 
respond with receipts 226 before it can make a final deter- 

50 mination as to whether to proceed with the transaction 214. 
Accordingly, the relying party 212 checks to determine 
whether there are any outstanding reliance manager requests 
for the transaction associated with this receipt/message pair. 
If not, the relying party can continue with the transaction 

55 214 with the subscriber 202, otherwise it continues to wait 
for replies from other reliance managers to other messages 
216 associated with the transaction 214. 

Based on the outcome reported in all receipts 226 
(corresponding to a particular transaction), the relying party 

60 212 can continue with the transaction. That is, having 
performed all checks and received guarantees and 
assurances, it may now proceed to actually rely on the 
transaction, 

2.C Form of User Certificate 
65 FIG. 11 shows the elements of a typical signer's certificate 
for use with the herein disclosed system. The certificate 
shown is an ITU X.509 certificate, and the additional fields 
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can be extensions as prescribed in X.509 Version 3. Each 
may be a separate extension, or the complete "reliance 
specification" can be a single Version 3 extension which 
contains multiple internal elements, or some combination of 
the two. 

As shown in FIG. 11, the reliance specification may 
contain at least: 

1. A statement that reliance is not recommended or 
assured above some nominal amount; This amount may 
increase if loss experience demonstrates that higher 
values do not pose an undue risk to the CA or its 
insurers and re-insurers. 

2. The name and optionally a network address of at least 
one status checking service approved by the issuing 
CA. If an X.500 directory lookup system is used, then 
the name and address will be one in the same. 
Otherwise, it may be necessary to specify a valid 
network address and means of communication. 

3. A schedule of basic fees for performing the services 
described in this embodiment, including the status 
check message (SCM), reliance guarantee request 
(RGR), over limit guarantee (OLG), and the "unrely" 
function (described below) in which the relying party 
voluntarily agrees to forego some or all of its right to 
rely on a given signature, thereby freeing a portion of 
the signer's reliance limit for the current period which 
can then be used on other transactions. 

4. An optional field granting permission for status check 
service to bill the signature guarantee fees to either the 
sender/signer or another third party (typically the sign- 
er's employer or sponsor) instead of requiring the 
relying party to pay them. When this feature is used, the 
status service will keep a record of the signature 
number (as elsewhere described) or of the signature 
value (or some value derived therefrom) to prevent the 
same or different relying party from utilizing the third 
party billing feature more than once. That is, the status 
service will detect that a specific digital signature has 
been checked and insured before, and will reject any 
attempt to re -check it at the sponsor's expense, which 
could result in waste of sponsor funds. 

5. When authorized, the name and account number of the 
third party who has agreed to cover the status check and 
guarantee fees. 

Alternatively, the certificate in question may not be an 
identity certificate which links a subscriber name to a public 
key, but rather one which confers some privilege or authority 
on the subscriber, in conjunction with an identity certificate, 
as described in U.S. application Ser. No. 08/682,071, titled 
"Method for Securely Using Digital Signatures in a Com- 
mercial Cryptographic System," the contents of which are 
hereby fully incorporated herein by reference. This is not to 
be confused with the "secondary certificate" of the first 
embodiment, which is analogous to the signature guarantee 
receipt of the second embodiment. Such an authorization 
certificate may also have an associated system of transaction 
limits which requires administration by a reliance manager, 
and accordingly will have added to it the same or a similar 
set of "reliance specification" fields as described above. 
2.D Quote Request 

The status check message may also contain a quote- 
request indicator along with a stated reliance amount, which 
will cause the reliance service to issue a quote for the cost 
of a full signature guarantee, but without actually issuing the 
guarantee. 

The quote issued by the reliance manager contains a 
unique identifier which can be used by the relying party in 
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connection with a subsequent signature guarantee request. If 
the guarantee request is received by the reliance manager 
soon after the original status check, then the guarantee can 
be issued without the computational overhead of performing 

5 the status check over again. In addition, the quote may 
specify a time period during which the guarantee can be 
issued without re-performing the check. In general, the 
quote wil] remain valid after this period expires, but the 
status checks will have to be performed over again, incurring 

10 the status check fee again. 
2.E The "Unrely" Function 

In a reliance management system, the issuing CA will 
typically assign a fixed reliance limit to each subscriber for 
a given period of time. For example, a lower level employee 

15 with some incidental procurement authority might be given 
a reliance limit of $1,000 per month. However, there will be 
numerous instances of transactions which, for one reason or 
another, do not go through, after they have been status 
checked by the prospective relying party, who purchased a 

20 signature guarantee, thereby depleting the signer* s allowed 
reliance limits for the time period in question. 

If the monthly time period is about to expire, the signer 
could merely wait an additional day, whereupon the system 
would reset his reliance limit back to $1,000. However, if he 

25 has already committed most of his limit and needs to 
perform additional transactions, this will be insufficient to 
allow him to continue working without intervention 

A straightforward solution to this problem is to allow the 
relying party, normally in his sole discretion, as an accom- 

30 modation to the signer/subscriber, to send a signed transac- 
tion to the reliance manager stating that he no longer intends 
to rely on the transaction in question, thereby relieving the 
reliance management system of any further exposure or 
obligation to pay damages for a possibly unauthentic trans- 

35 action. The user's reliance limit can be re-credited in full, 
although the system will retain the status check fee, and 
possibly some portion of the signature guarantee fee. 

As an extension, a relying party may partially rely on a 
signature in attempting to execute a transaction, but then the 

40 transaction is never consummated. For example, a customer 
might send a "limit order" to a stock broker, who then 
attempts to execute the order at the price specified by the 
customer, but due to price fluctuations in the marketplace, 
the order is never executed, because the price requirements 

45 were never met. In this case, the reliance management 
system has been exposed to the peril or risk that the order 
might have been placed using an inauthentic signature, so 
some element of the guarantee fee has been earned (possibly 
measured by the transaction fees to make and then undo the 

so trade), but the system has not been exposed to the full risk 
of loss of principal which would have arisen by delivering 
the securities to an unknown person based on a forged 
transaction. 

The parties to various major transaction systems can agree 
55 in advance to a re-credit schedule for failed transactions, or 
possibly the relying parties (e.g., stockbrokers) may elect to 
absorb the fees and make them up by cross-subsidization 
from profitable transactions. Such fee chargeback and reli- 
ance release schedules may also be elements of the reliance 
60 manager service offering, and may appear in the certificates 
of the reliance service, the subscriber, or the broker. 

The "unrely" transaction references a specific previous 
transaction which the relying party had received from a 
specific signer, and on which a guarantee has been issued, 
65 and will state the old and new (smaller, possibly $0) reliance 
amounts, signed by the relying party with an attached 
certificate in the event the relying party does not have an 
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account with the status service. The status service will 
re-credit the difference to the signer/subscriber's reliance 
limit for the current period. 
2.F Signature Guarantee Txme Periods 

In a reliance management system for digital signatures as 
described herein, it is desirable to underwrite (guarantee, 
insure etc.) the authenticity of digital signatures where the 
starting and ending times for the guarantee period may be 
selectable by the parties. The main reason for this is that 
insurers may thereby be able to reduce the cost of the 
guarantee fee if their risks have been appropriately reduced 
by such additional means. 

The highest level of risk of reliance on a digital signature 
generally comes immediately upon receipt, because the 
signature may have been made by an unauthorized person 
who improperly gained access to the signing device of the 
legitimate user, possibly by stealing it, along with knowl- 
edge of its activation code or P[N number, but there has been 
insufficient time for the legitimate user to detect the theft and 
contact the CA to request that their certificate be revoked. 
Indeed, this interval of risk is the one for which the reliance 
management service described herein permits commerce to 
proceed in a timely manner even in the face of possible 
forgery losses, by mutualizing those losses in an insurance 
based system. 

a. Delayed Start of Reliance 

When a prospective relying party is in a position to "hold" 
a transaction for several hours, days, or even weeks prior to 
actually relying on it, the status service may be able to quote 
a lower signature guarantee fee, because the putative signer 
will have had much more time to detect and report the theft 
or unauthorized use of their signing device. This risk reduc- 
tion effect will be greatest when the intended relying party 
purchases a guarantee from the reliance service which can 
then be reported to the signer/subscriber as part of their 
periodic paper or electronic statement. When the signer sees 
the unauthorized transaction, they can report it to the status 
service, which can then notify the relying party before they 
actually rely on it. A lesser risk reduction effect can be 
achieved by almost any degree of delay, even as little as one 
to two hours, since that can give the legitimate user more 
time to discover that their signing device is missing and 
report that to their CA and reliance service. 

b. Reduced Tail of Reliance 

Insurers prefer to assume risks with shorter coverage 
periods. Some digital signatures may need to be relied upon 
for long periods of time. For example those protecting 
deeds, mortgages, wills, laws or treaties may need to remain 
verifiable and reliable for twenty years or more, while major 
commercial contracts may need up to ten years of reliance. 
However, the vast bulk of minor transactions will settle and 
be forgotten within a few weeks or months, after which an 
authentic digital signature is not really needed as evidence, 
because many other facts now exist which would prevent the 
signer from denying the signature's authenticity. For 
example if a contract buy or sell goods, services, or financial 
instruments has been fully performed on both sides, and 
some number of months has gone by, the relying party may 
no longer feel a strong need to be protected against a late 
claim of forgery or fraud. Therefore the relying party can (a) 
request a shortened guarantee period from the reliance 
service, or (b) at some point issue an unrely transaction in an 
attempt to recover part of the reliance guarantee fees paid. 

FIG. 12 illustrates the risk, time, and cost considerations 
discussed in the preceding paragraph. Whenever possible, 
the sophisticated relying party will seek to insure only its 
actual exposure, thereby reducing its guarantee fees. In the 
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example shown, the relying party does not need to rely on 
the transaction (a) until time Tl, after which the risk of an 
unreported forgery has already been significantly reduced, 
and (b) after time T2, thus eliminating the need for "long 

5 tail" insurance coverage far into the future. The premium 
paid for the signature guarantee may be proportional to the 
area under the curve between the two vertical lines labeled 
Tl and T2. 

c. Multi-Stage Reliance Pricing 

10 In many business contexts, a document may be relied 
upon multiple times by different parties for different pur- 
poses. An example might be a deal closing in which an 
inventory of property (a) is transmitted to a lender or 
investor in anticipation of a possible loan or financing and 

j 5 relied upon by that party in preparing a financial agreement, 
and (b) is certified and filed as part of a security agreement 
under the financial agreement as an element of the closing 
process. Another example might be a vehicle title which is 
relied upon to obtain (a) purchase or lease financing, (b) 

20 liability insurance, and (c) license plates. However, there is 
always the possibility that the transaction might be delayed 
or aborted at any step along the way. Therefore in the context 
of a pre-defined multi-stage transaction, the reliance service 
may quote a discount price for a series of guarantees of same 

25 signature on the same document issued to the same or 
different parties, and then bill for each according to the stage 
being completed. 

The reliance request message to the status service will 
then include a transaction class and unique identifier that 

3 q identifies the initiation and continuation of a particular type 
of multi-stage transaction (e.g., a home mortgage closing), 
with a special price being quoted for each transaction stage, 
or for all stages as a set. If a transaction receipt stated to be 
for a given stage were actually relied on for a different stage 

35 of the transaction, the guarantee would be void. 
2.G Portfolio Risk Management 

In another embodiment, the CAor other sponsor sends an 
array of data values describing the permitted activities of the 
signer/subscriber (and any firm or group to which they may 

40 belong) to the reliance server database, and provides that the 
reliance server may independently manage each of those 
data values in response to transactions that are sent to it for 
status checking and signature guarantees (confirmation). 
For example, a financial institution may employ various 

45 groups of agents to execute different types of financial 
transactions, and may seek to limit its financial risks by 
imposing firm-wide policies regarding various types of 
risks, and then disallowing or requiring special permission 
for transactions that would violate these policies. Typically 

50 the firm's credit and risk management department develops 
and administers these limits. Some examples include the 
following: 

1. To manage "credit risk/' which is the risk that a 
counterparty will be unable to pay (settle) outstanding 

55 transactions, the firm will decree a maximum exposure 
on uncleared trades with each counterparty, such that 
the amount of money or securities currently owed to or 
from that counterparty cannot exceed a specified value, 
such as $50 million. These limits may be readjusted as 

60 new information becomes available that either 
increases or decreases the creditworthiness of a given 
counterparty, or class of counterparties. 

2. To manage "currency risk," which is the risk of sudden 
foreign currency price changes, the firm may decree 

65 that the total amount of money or securities owed to or 
from all counterparties that are denominated in a par- 
ticular foreign currency (such as the Japanese Yen) 
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cannot exceed some stated value, such as $2 billion. In 
this manner, if the Yen-Dollar exchange rate makes a 
large and sudden change, the firm's total maximum risk 
is known and controlled in advance. 

3, To manage "political risk," which is the risk that a given s 
country's government might impose unfavorable eco- 
nomic or legal policies (including at worst the expro- 
priation of foreign owned assets), the firm may decree 
that the total amount of securities linked to each foreign 
economy (such as South Africa) cannot exceed some 1Q 
stated value, such as $1 billion. In this manner, if the 
South African government suddenly seized all foreign 
assets and refused to pay foreign debts, the firm's total 
maximum risk is known and controlled in advance. 

4, To manage the "regional or industry risk/' which is the ^ 
risk that financial assets (such as stocks or bonds) 
associated with a particular geographic region (New 
England, the Rust Belt, Eastern Europe, Silicon Valley, 
etc.) or type of industry (steel, autos, airlines, 
chemicals, computers, etc.), the firm may decree that 
the total amount of securities linked to each given 20 
region or industry cannot exceed some stated value, 
such as $500 million. In this manner, if the price of oil 
were to quadruple, causing airline stocks to decline in 
value, the firm's total maximum risk is known and 
controlled in advance. 25 

As each day's transactions are settled, the firm's outstand- 
ing exposure to each type of risk limit is recalculated and 
reinitialized, so employees can enter into other transactions. 
Periodically, the outside limits themselves are reviewed and 
adjusted taking into account the perceived level of volatility 30 
and risk in each class of risk, and the firm's capital position 
and appetite for risk. In addition, exceptions or system 
over-rides may be made on a manual or semi-automated 
basis, if a sufficient business case exists for the firm to 
tolerate the extra risk, possibly only on a short term basis 35 

The forgoing risks and others like them can be centrally 
and automatically administered by a reliance service such as 
the one described herein, provided that the reliance server is 
provided with the data content of every transaction to be 
checked. The transactions are not valid until they are con- 40 
firmed by the central reliance service operated or contracted 
by the firm. On a periodic (usually daily) basis, the Firm 
updates the database of the reliance service with the cur- 
rently authorized limits, and during the day the transaction 
flow works against these limits. Of course some transactions 45 
which decrease exposure, such as (a) selling Yen for Dollars, 
or (b) selling General Motors stock for cash will increase the 
available exposure limits for the Yen (currency) and the 
automotive industry, respectively. Also the overnight settle- 
ment of trades will reduce the amount of money owed to or 50 
owed by counterparty firms, thereby releasing some or all of 
their allowed their credit limits. 

Accordingly, the reliance server is modified to store 
information needed for administering risk exposure limits 
generated as a result of transactions originated by the 55 
employees a given firm. The firm updates this information 
on a regular basis, and the reliance system decreases or 
increases available limits according to the transactions being 
presented to it for reliance checking. 

This system can yield a large cost savings and efficiency 60 
increase, since it (a) provides a convenient central point for 
administering all such transactions, not only for one firm but 
for many, thereby replacing many fragmented systems that 
are often administered on an after the fact basis, and (b) it 
can effectively force nearly 100% compliance, since trans- 65 
actions are not valid and will not be paid unless counter- 
signed by the status/reliance checking service. 



Such a system can also enforce economic policies at a 
regional, state, or national level in response to controls 
imposed by governments or trade organizations, such as to 
enforce currency exchange controls, or to limit the import or 
export of a particular commodity. That is, a governmental 
entity or trade organization might decline to enforce, or 
place differential taxes upon, transactions depending on their 
content, direction, monetary value, etc. analogous to the 
preceding firm-wide system. A receipt from a designated 
reliance service would be required for all transactions seek- 
ing to comply with the control system. The reliance server 
could then enforce a set of limits designed to conserve scarce 
foreign exchange reserves, as for example in a developing 
country. 

Thus, a reliance manager for an electronic transaction 
system is provided. One skilled in the art will appreciate that 
the present invention can be practiced by other than the 
described embodiments, which are presented for purposes of 
illustration and not limitation, and the present invention is 
limited only by the claims that follow. 

What is claimed: 

1. A method of managing reliance in an electronic trans- 
action system, the method comprising the steps of: 

(A) a certification authority issuing electronic signals 
representing a primary certificate to a subscriber; 

(B) forwarding, from the certification authority to a reli- 
ance server, electronic signals representing information 
about the issued primary certificate; 

(C) the reliance server maintaining the forwarded infor- 
mation about issued primary certificate; 

(D) the subscriber forming a transaction and then provid- 
ing electronic signals representing the transaction to a 
relying party, the transaction including electronic sig- 
nals representing the primary certificate; 

(F) the relying party sending to the reliance server elec- 
tronic signals representing a request for assurance 
based on the transaction received from the subscriber; 

(F) the reliance server determining whether to provide the 
requested assurance, said determining based on the 
information about the issued primary certificate and on 
the requested assurance; and, based on said 
determining, 

(G) the reliance server issuing to the relying party elec- 
tronic signals representing a secondary certificate pro- 
viding the assurance to the relying party. 

2. A method as in claim 1 further comprising the steps of: 
(I) the reliance server and the relying party entering into 

a contract prior to the reliance server issuing the 
secondary certificate. 

3. A method as in claim 2 wherein the contract is entered 
into after the relying party makes its request. 

4. A method as in claim 1 wherein the primary certificate 
specifies a reliance limit and wherein the information for- 
warded by the certification authority to the reliance server 
includes electronic signals representing assurance param- 
eters controlling whether the reliance server can provide 
assurance based on the primary certificate. 

5. A method as in claim 4 wherein the assurance param- 
eters include electronic signals representing an acceptable 
reliance limit in excess of the reliance limit specified in the 
primary certificate, and wherein the request for assurance is 
a request for reliance on a value in excess of the specified 
reliance limit, wherein the step (F) of the reliance server 
determining whether to provide the requested assurance 
comprises the step of: 

(Fl) determining whether the requested reliance would 
exceed the acceptable reliance limit. 
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6. A method as in claim 5 further whether comprising the 
step of: 

(H) the reliance server tracking cumulative liability asso- 
ciated with the primary certificate, and 

wherein the step (Fl) of determining comprises the step 
of: 

(F2) determining whether the requested reliance would 
cause the cumulative liability to exceed the accept- 
able reliance limit. 

7. A method as in claim 4 wherein the requested assurance 
is for the accuracy of another certificate, and wherein step 
(F) further comprises the step of: 

(Fl) the reliance server checking the current validity and 
authenticity of the other certificate; and wherein the 
step (G) of issuing comprises the step of: 

(Gl) the reliance server issuing electronic signals repre- 
senting the secondary certificate attesting to the accu- 
racy of the other certificate. 

8. A method as in claim 7 wherein the step (Fl) of 
checking comprises the steps of: 

verifying the other certificate's digital signature along a 

chain of certificates, and 
checking whether the requested assurance is within the 

assurance parameters. 

9. A method as in claim 4 wherein the requested assurance 
is for the authenticity of another certificate, and wherein step 
(F) further comprises the step of: 

(Fl) the reliance server checking authenticity of the other 
certificate; and wherein the step (G) of issuing com- 
prises the step of: 

(Gl) the reliance server issuing electronic signals repre- 
senting the secondary certificate attesting to the authen- 
ticity of the other certificate. 

10. A method as in claim 9 wherein the step (Fl) of 35 
checking comprises the steps of: 

verifying the other certificate's digital signature along a 

chain of certificates, and 
checking whether the requested assurance is within the 

assurance parameters. 

11. A method as in claim 4 wherein the requested assur- 
ance is for the validity of another certificate, and wherein 
step (F) further comprises the step of: 

(Fl) the reliance server checking the current validity of 
the other certificate; and wherein the step (G) of issuing 
comprises 

(Gl) the reliance server issuing electronic signals repre- 
senting the secondary certificate attesting to the validity 
of the other certificate. 

12. A method as in claim 11 wherein the step (Fl) of 
checking comprises the steps of: 

determining whether the other certificate has been 

suspended, revoked, or has expired, and 
checking whether the requested assurance is within the 

assurance parameters. 

13. A method as in claim 4 wherein the requested assur- 
ance is for assurance of an agent's authority and wherein 
step (F) further comprises the step of: 

the reliance server returning electronic signals represent- 
ing documentation of agency with an enveloping sec- 
ondary certificate attesting to authenticity. 

14. A method as in claim 13 wherein the documentation 
of agency includes a power of attorney. 

15. A method as in claim 4 wherein the requested assur- 
ance is for assurance of a person's accreditation and wherein 
step (F) further comprises the step of: 
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the reliance server returning a statement by a licensing or 
professional body regarding the person's accreditation, 
with electronic signals representing an enveloping sec- 
ondary certificate attesting to the statement's authen- 
ticity. 

16. A method as in claim 4 wherein the requested assur- 
ance is for assurance of at least one of existence and good 
standing of entity and wherein step (F) further comprises the 
step of: 

the reliance server returning electronic signals represent- 
ing a statement by a public office in which the entity is 
incorporated indicating that the entity exists, is in good 
standing, and is qualified to conduct business, wherein 
statement is enclosed in the secondary certificate attest- 
ing to the statement's authenticity. 

17. A method as in claim 4 wherein the requested assur- 
ance is for assurance of the performance of an obligation and 
wherein step (F) further comprises the step of: 

the reliance server issuing electronic signals representing 
a statement of assurance of payment, wherein statement 
is enclosed in the secondary certificate attesting to the 
statement's authenticity. 

18. A method as in claim 4 wherein the transaction 
includes electronic signals representing a digital signature 
and wherein the assurance parameters include electronic 
signals representing a maximum supplemental assurance 
that can be issued for a particular digital signature. 

19. A method as in claim 4 wherein the assurance param- 
eters include electronic signals representing at least one of: 

a maximum supplemental assurance that can be issued in 
a single secondary certificate; 

a maximum supplemental assurance that can be issued to 
any particular relying party; 

a maximum supplemental assurance that can be issued 
during one or more specified time intervals; 

a maximum number of secondary certificates that can be 
issued on the primary certificate; 

a maximum time period during which a secondary cer- 
tificate may remain valid; 

a maximum reliance limit that can be listed in a secondary 
certificate valid for a specified transaction type; 

specific information that must be submitted by the relying 
party along with its request in order to provide a basis 
for the supplemental assurance; 

an amount of supplemental assurance that the subscriber 
has prepaid and restrictions on how that prepaid assur- 
ance can be issued in a secondary certificate; 

a requirement that the subscriber approve issuance of 
supplemental assurance by the reliance server for a 
secondary certificate to be issued to the relying party 
before a relying party's request for a secondary certifi- 
cate can be granted; 

thresholds which trigger a report being sent from the 
reliance server to the certification authority; 

how often the reliance server should report to the certi- 
fication authority about the extent of supplemental 
assurance issued on the primary certificate; 

signals representing restrictions limiting disclosure of or 
access to the primary certificate to specified parties; 

requirements that the transaction be signed by additional 
parties besides the subscriber, optionally specify who 
those additional parties are and what number of them 
must sign; 

a scale of the amount of supplemental assurance that can 
be issued based on the number and identity of addi- 
tional parties that sign; and 
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information regarding the validity of the primary certifi- creating a message based on certificate information from 

cate. the transaction, the message specifying an amount of 

20. A method as in claim 19 wherein an assurance the transaction upon which the relying party intends to 
parameter can be restricted to a particular time period. rely; and 

21. A method as in claim 20 wherein the particular time s sending electronic signals representing the message to a 
period is the entire period during which the primary certifi- reliance server requesting a guarantee for the amount of 
cate is valid. me transaction upon which the relying party intends to 

22. A method as in claim 19 wherein the specific infer- rely. 

mation includes electronic signals representing some of a 28. Amethod as in claim 27 further comprising the steps 

specific class of certificate that has been promised to the io 0 f, the relying party: 

relying party, specification of a transaction type and a second ' receiving electronic signals representing a voucher from 

signature. ^ rc i{ ance server in response to the step of sending the 

23. An electronic transaction system comprising: message' and 

a certification authority issuing electronic signals repre- ' lhe transaction with the subscriber based on 

seating primary certificates to subscribers to the sys- is information in the voucher. 

tern, an 29. A method of managing reliance in an electronic 

a reliance server connectable to the certification authority transact i 0 n system in which subscribers have digital time- 

and receiving from the certification authority electronic based certificates issued by certification authorities, the 

signals representing information regarding the primary mcthod prising the steps of, by a reliance server: 

certificates issued by the certification authonty, the 20 . . . . 

r .el- receiving electronic signals representing a reliance 

reliance server issuing, upon request from relying * c ^ fi • 

, A . . & . ^ , request message from a party, the message specifying 

parties, electronic signals representing secondary cer- n ? »■ l * • _r 

\„ ' . , . & . . . i jt an amount of a transaction upon which the party 

tificates to the relying parties, the issuing being based . . A . . , t . r * c *u 

4t _ . c *■ -j ji? *u *• intends to rely and requesting a guarantee for the 

on the information provided by the certification author- *• *u • i j- 

, . r 5 J , , 4 . . . _ 4 . amount of the transaction, the message including cer- 

lty and on information provided by the relying parties. 25 . . ' ^ & 

- - ' 4 • i • v» r • • tificate information derived from the transaction: 

24. A system as in claim 23 further comprising: . . , , . , , . 

t , . t , , . . . ! • determining whether to provide a guarantee for the 

at least one other party connectable to the reliance server, . r iL . j 

wherein the reliance server provides the electronic amount of 1116 transactlon ; and 

signals representing the secondary certificate to the sendin g electronic signals representing a voucher to the 

other party prior to issuing the electronic signals rep- 30 relying party, the voucher including an indication of 

resenting the secondary certificate to the relying party. whether the reliance server guarantees the amount of 

25. A system as in claim 23 wherein the reliance server the transac t 10 n- 

digitally signs the secondary certificate prior to issuing it to 30 - A method as in cIaim 29 wherein me ste P of deter " 

the relying party. mining further comprises the step of: 

26. In an electronic transaction system in which a certi- 35 determining whether certificates associated with the trans- 
fication authority issues electronic signals representing digi- action have been revoked or suspended. 

tal certificates to subscribers, a method of automatic replace- 31. A method as in claim 30 further comprising the steps 

ment of a subscribers certificate, the method comprising the of: 

steps of, by a subscriber: receiving from the certification authority electronic sig- 

(A) creating a standby application for certification of a 40 nals representing an actual reliance limit for a certifi- 
new key pair; cate; 

(B) digitally signing the standby application with a private storing the actual reliance limit; and 

key and then destroying the private key; determining whether the requested amount would exceed 

(C) including electronic signals representing the public ^ the actual reliance limit. 

key corresponding to the private key in a transactional 32. A method as in claim 31 further comprising the step 

certificate valid only for the standby application and of maintaining a cumulative liability for a certification 

forwarding the transactional certificate to the certifica- authority. 

tion authority; and, by the certification authority, 33. A method of managing reliance in an electronic 

(D) keeping electronic signals representing the transac- 5Q transaction system, the method comprising the steps of, by 
tional certificate; and subsequently, a certification authority: 

(E) the subscriber sending electronic signals representing issuing electronic signals representing a time-based cer- 
the standby application to the certification authority; tificate to a subscriber, the certificate specifying a stated 

(F) the certification authority verifying the digital signa- reliance limit; and 

ture on the application by reference to the transactional 55 forwarding to a reliance server electronic signals repre- 

certificate; and then senting an actual reliance limit for the certificate, the 

(G) issuing electronic signals representing a new time- actual reliance limit being different from the stated 
based certificate listing the public key indicated in the reliance limit. 

standby application. 34. A method of managing reliance in an electronic 

27. A method of managing reliance in an electronic 60 transaction system in which subscribers have digital 
transaction system in which subscribers have digital time- certificates, the method comprising the steps of, by a relying 
based certificates issued by certification authorities, the party: 

method comprising the steps of, by a relying party: receiving electronic signals representing a transaction 

receiving electronic signals representing a transaction from a subscriber, the transaction including informa- 

from a subscriber, the transaction including informa- 65 tion regarding at least one certificate of that subscriber; 

tion regarding at least one time-based certificate of that creating electronic signals representing a message based 

subscriber; on certificate information from the transaction, the 
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message specifying an aspect of the transaction upon 
which the relying party intends to rely; and 
sending the electronic signals representing the message to 
a reliance server requesting a guarantee for the aspect 
of the transaction upon which the relying party intends s 
to rely. 

35. A method as in claim 34 further comprising the steps 
of, the relying party: 

receiving electronic signals representing a reply receipt 
from the reliance server in response to the step of 10 
sending the message; and 

continuing the transaction with the subscriber based on 
information in the reply receipt. 

36. A method as in claim 35 wherein the message 
requested certificate status checks and the reply receipt 
indicates whether the certificate status checks were accept- 
able. 

37. A method as in claim 35, wherein the receipt indicates 
whether the reliance server guarantees the aspect of the 
transaction upon which the relying party intends to rely. 

38. A method as in claim 34 wherein some of the 
subscriber's certificates have associated fees, the method 
further comprising the step of, the reliance server: 

ascertaining a fee for its services based on the fees of 2 s 
certificates associated with the transaction. 

39. A method as in claim 38 wherein the fees include 
usage fees, guarantee fees and lookup fees. 

40. A method as in claim 34 wherein the aspect of the 
transaction upon which the relying party intends to rely 30 
specifies a monetary value and the receipt indicates whether 
the reliance server guarantees the transaction for that mon- 
etary value. 

41. A method as in claim 40 wherein the reliance server 
bases its guarantee on information specified in a certificate 35 
associated with the transaction. 

42. A method of managing reliance in an electronic 
transaction system in which subscribers have digital 
certificates, the method comprising the steps of, by a reli- 
ance server: 40 

receiving electronic signals representing a message from 
a party thereby requesting a guarantee for an aspect of 
the transaction, the message including certificate infor- 
mation derived from the transaction; 

validating information in the message to determine 45 
whether to provide the guarantee for the aspect of the 
transaction; and 

sending electronic signals representing a reply receipt to 
the relying party, the reply receipt including an indi- 
cation of whether the reliance server guarantees the 50 
aspect of the transaction. 

43. A method as in claim 42 wherein the step of validating 
further comprises the step of: 

determining whether certificates associated with the trans- JS 
action have been revoked or suspended. 

44. A method as in claim 43, wherein the certificate 
information included in the message includes unique iden- 
tifiers for certificates associated with the transaction, and 
wherein the step of determining comprises the step of: 6Q 

looking up unique certificate identifiers on certificate 
revocation lists. 

45. A method as in claim 43, wherein the step of deter- 
mining is performed based on previously obtained informa- 
tion about certificates. 
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46. A method as in claim 43 wherein the aspect of the 
transaction for which a guarantee is requested is a monetary 
reliance value, and wherein at least one certificate associated 
with the transaction specifies a monetary limit, the step of 
validating further comprising the steps of: 

determining whether the monetary reliance value is within 
the monetary limit specified in the certificate. 

47. A method as in claim 46, wherein the step of deter- 
mining further comprising the steps of: 

obtaining a value of a current cumulative monetary liabil- 
ity for the certificate; 

determining whether the sum of the monetary reliance 
value and the current cumulative monetary liability 
would exceed the specified monetary limit; and, based 
on this determining, 

updating the current cumulative monetary liability. 

48. A method of managing reliance in an electronic 
transaction system, the method comprising the steps of: 

a certification authority issuing electronic signals repre- 
senting a time -based certificate to a subscriber; 

forwarding, from the certification authority, electronic 
signals representing information about the certificate to 
a reliance server, the information including a unique 
identifier for the certificate and an actual reliance limit 
for the certificate; 

the subscriber forming electronic signals representing a 
transaction based on the certificate and forwarding the 
transaction to a relying party; 

the relying party sending electronic signals representing a 
reliance request message to the reliance server con- 
cerning the transaction; 

the reliance server checking information in the reliance 
request message, and, based on the checking; 

issuing electronic signals representing a transactional 
certificate as a voucher to the relying party. 

49. A method as in claim 48 wherein the time-based 
certificate includes a stated reliance limit which is zero. 

50. A method as in claim 48 wherein the reliance request 
message specifies an amount of the transaction upon which 
the relying party intends to rely, 

51. A method as in claim 50 wherein the step of checking 
comprises the step of determining whether the specified 
amount would exceed the certificate's actual reliance limit. 

52. A method as in claim 48 wherein the certificate states 
that reliance on the certificate can only be made if the 
certificate is checked with a reliance server. 

53. A method as in claim 52 wherein the certificate 
specifies the reliance server. 

54. A method as in claim 52 further comprising the step 
of the reliance server digitally signing the transactional 
certificate. 

55. A method as in claim 52 further comprising the steps 
of, by the reliance server: 

forwarding the electronic signals representing the trans- 
actional certificate to at least one other party; 

receiving the electronic signals representing the transac- 
tional certificate from another party; and 

digitally signing the transactional certificate, 

56. A method as in claim 55 further comprising the step 
of the other party digitally signing the transactional certifi- 
cate. 

***** 
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